RE: [sv-ac] AC 196 - optional type spec?

 Hillel,

My point was that (a, type_spec1 x, y, type_spec2 v, w) would be interpreted
using the current BNF as wire a. The intent is to have "a" to be a sequence,
for example. If you define new syntax, it would have to have the untyped
arguments in front of the typed ones, I think. I.e., a would be the untyped
arg.
ed

> -----Original Message-----
> From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
> Sent: Tuesday, November 16, 2004 12:48 PM
> To: 'Eduard.Cerny@synopsys.com'; Sv_Ac
> Cc: Miller Hillel-R53776
> Subject: RE: [sv-ac] AC 196 - optional type spec?
>
> Ed,
>
> As stated before to allow backward compatibility the proposal
> needs to have a BNF of its own, which steals the majority of
> the existing tf_port_list BNF.
> There cannot be an implicit type or an ommited type. Anything
> without a type stays as today. Therefore one would need to
> write the below.
>
> (wire a, type_spec1 x, type_spec1 y, type_spec2 v, type_spec2 w)
>
> Hillel
>
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]On
> Behalf Of Eduard Cerny
> Sent: Saturday, November 13, 2004 1:05 AM
> To: Sv_Ac
> Cc: Eduard Cerny
> Subject: [sv-ac] AC 196 - optional type spec?
>
>
> Hello,
>
> It seems to me that there may be a problem in allowing
> optional type specification on formal arguments to sequences
> and properties for the following reason:
>
> If I understand the LRM correctly, a tf_port_list can be specified as
> follows:
>
> (a, type_spec1 x, y, type_spec2 v, w)
>
> in this case a is of type wire (?), x AND y are of type
> type_spec1, v AND w are of type type_spec2.
>
> How does one distinguish omitted type from a type propagating
> from a preceding declaration or be implicit?
>
> Can we add a restriction such that untyped formals are
> specified first, followed by typed formals? In that case a in
> the above example would be untyped.
>
>
> ed
>
>
>
Received on Tue Nov 16 10:28:50 2004