Subject: Re: [vhdl-200x] A 2nd proposal to boolean equivalence
From: Tim Davis (timdavis@aspenlogic.com)
Date: Tue Dec 23 2003 - 15:05:20 PST
Evan Lavelle wrote:
> Tim Davis wrote:
>
>> So, by extrapolation, I think what people might be looking for is a
>> way to "overload" the if-then-else statement. (We have overloaded
>> names, overloaded operators, overloaded functions, why not overloaded
>> statements?) I suspect that might be a little tough to put together
>> syntactically.
>
> Overloading statements makes a language mutable, rather than just
> extensible.
I understand. Interpretered languages (such as TCL) are mutable and
while it has advantages it can also be god awful difficult to debug. I
was suggesting the idea as "thinking food". I'm glad you ate some!
> In addition, VHDL is already notoriously difficult to write compilers
> for; I suspect that making the basic statements themselves dependent
> on context would make it very difficult.
Not anymore. While I can't profess to have personally constructed a
compiler I've read that it is difficult but not hard do to new compiler
generation tools. C++ is extremely difficult and hand constructed
parsers are a requirement and not an option.
>> Unfortunately, VHDL makes this hard on us by requiring the selector
>> expression to be static. Lets remove that requirement. While the use
>> of case statements in place of if statements may seem unpalitable to
>> some I would do it in a heartbeat. Absolutely no confusion over
>> positive/negative logic would be a windfall.
>
>
> I'm all in favour of generalising 'case', but it would have to done
> with a new statement to make it backwards-compatible. non-Veriloggers
> should see
>
> <http://www.sunburst-design.com/papers/CummingsSNUG1999Boston_FullParallelCase_rev1_1.pdf>
>
>
> for a summary of the synthesis problems associated with more general
> case statements. I also particularly like the 'e' 'boolean case'
> statement, ie (although it doesn't address the boolean equivalence
> problem):
>
> case {
> boolean_expr { actions };
> another_boolean_expr { actions };
> default { actions };
> };
I don't understand why you think a new case statement would be
necessary. It is just a matter of allowing the selector expression and
the matching elements to be non-static. (Maybe I don't understand you.)
>> Second, lets add the boolean selector operator "?" which many
>> languages have now and permit it to be overloaded.
>
> It's interesting that not even C++ allows ?: to be overloaded,
> although it does allow almost everything else (another 42 operators)
> to be overloaded. I don't know why, but I suspect it's the mutability
> issue.
I'm guessing it is because it is really a split operator -- the '?' and
':' must go together. Hence it doesn't really parse like a binary
operator. Maybe that is harder to do.
>> Third, (as I proposed before) utilize enumerated type declarations
>> with explicit type equivalency built into the declaration. Here is
>> the syntax I proposed:
>>
>> type negative_logic is ('0' => true, '1'=>false, 'Z'=>false,
>> 'X'=>false) with boolean,
>> ('0'=>1, '1'=>0, 'Z'=>-1, 'X'=>-1)
>> with integer,
>> ('0' => "0", '1'=>"1", 'Z'=>"Z",
>> 'X' => "X") with string;
>
>
> If you want boolean equivalence, then it seems to me that this is a
> much cleaner, simpler and better way of achieving it. However, the
> overall effect is the same: the compiler is allowed to carry out
> implicit typecasting without any explicit request (at the point at
> which it is required) from the user.
It is an explicit (and user controllable) definition of the type
equivalence for use in implicit type conversions at the point of
reference. It doesn't destroy strong typing as the compiler can still
verify that a correct type is present. As such it has value in the
following situation:
SIGNAL rocket_launch : std_logic;
...
REPORT "rocket_launch=" & rocket_launch;
(It would also eliminate the need for my previous request for DeMorgan
equiv operators as {AND, OR, etc.} would just be overloaded to work with
type negative_logic.)
For what ever it is worth I like the explicit type casting approach
better then an implicit one. I'm vehemently (spitting and gaging omited)
opposed to pkgs like std_logic_unsigned because they eliminate the need
for type casting from std_logic_vector to unsigned. I think that is
important descriptive information to the reader. However, I'm **NOT**
opposed to the fact that VHDL permits such packages to be constructed
and work usefully (for some). Their presence is a powerful testament to
the original language designers brilliance.
So even if my declarative approach above was possible, I would still use
IF (rocket_launch='0') THEN ...
or
CASE rocket_launch IS
'0' => ...
'1' => ...
because it makes the logic system unambiguously clear to the reader at
the point where it is most usefull. The fact that certain users think
that it is to much typing is irrelevant to me.
(By the way -- thanks for listening this far.)
-- Aspen Logic, Inc. By: Tim Davis, President
This archive was generated by hypermail 2b28 : Tue Dec 23 2003 - 15:07:14 PST