Re: [vhdl-200x-ft] Revised FT18: condition operator

Tristan,
>>Note, condition? was (is being) replaced by ?? as updated below:
>>
>>>Instead of
>>> *condition* ::= *boolean*_expression
>>> | ??( expression )
>>>
>>> Where ?? is called by the compiler when the expression does
>>> not resolve to boolean.
>>
>>In this from of condition, ?? can only be called
>>implicitly at the highest level of the condition.
>>The expression must hence resolve to some type such
>>as std_logic or bit for ?? to be called.
>>
>>
>>>Why not:
>>> *condition* ::= expression
>>>
>>> Where a "??" function returning a boolean is implcitly called with the
>>> expression as only argument.
>>
>>When is ?? called? Anytime? We looked at that.
>>If you demote std_logic to boolean too soon, you
>>loose the value of X. If A is 'X', should "not A"
>>translate to false (applying it after the not) or
>>true (applying ?? to A immediately). I think
>>John Ries was able to come up with some more
>>interesting cases than this.
>
> I was not clear enough. In the second form (the one I have written),
> the "??" function is always implicitly called at the highest level of a
> condition. Therefore, boolean is not that special anymore (exception that only
> function "??" returning a boolean are considered).

Agree.
As long as it is only implicitly called one time we are ok.

>
> [...]
>
>>P.S.
>>Of course, as a hardware designer, I never saw the
>>value of having a separate type for boolean. So
>>long term, I would like to see it easier to move
>>back in forth between them. Something more like:
>>
>> As an expression is being evaluated, promote booluean
>> to bit and boolean to std_ulogic as needed. Optionally
>> extend this to include bit to std_ulogic.
>>
>> When an expression is being assigned
>> or has reached a conditional demote the expression
>> value as needed. From std_ulogic to boolean and
>> bit to boolean as needed. Optionally extend this to
>> include std_ulogic to bit.
>>
>>
>>In the future we probably need some general mechanism for
>>defining type association. If we were to write something
>>like the above into the LRM now, it is potentially a wart
>>that would either need to be worked around in the future.
>
> That's a real debat, and it seems you like Verilog point of vue on this
> issue!!!
> I do like strong typing and I do like the difference between boolean and
> bit/std_logic. It clearly separates data-flow from control-flow.

I like strong typing too. I just hate boolean.
Imagine VHDL without boolean. I don't see it as
data-flow vs control-flow.

I see it as replacing (data-flow):
   Reg1Sel <= '1' when DevSel = '1' and Addr(2 downto 0) = REG1_ADDR
              else '0' ;

With (?data-flow?):
   Reg1Sel <= DevSel and (Addr(2 downto 0) = REG1_ADDR) ;

It is sad as if we had never had boolean, the "=" above
could have propagated 'X's if a bit of Addr had an 'X' or
ignored bits if a bit of REG1_ADDR contained '-'.
As it stands, "=" must coerce things into true/false.
To do something more accurate, we would need to introduce
new operators.

Cheers,
Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~