Hi All, We have many intertwined issues that revolve around 1549 and discussion it brought forth in particular arg passing/pass by ref or value/"substitution" semantics so I think we should agree on and pin down some rules of "understanding" that cut across all the issues otherwise we'll keep going in circles without this foundation... here's a suggested informal starting set which I believe is self-consistent: a) pass by "substitution" semantics go hand in hand (and only) with "untyped" args: Meaning compiler has to look "inside" to do semantic checks -- keep the substitution (like a macro) semantics we have in LRM, more clearly state this as a passing mechanism, and tie to untyped only. c) pass by ref goes hand in hand (and only) with strict typing : Meaning compiler first looks at type and does (first level of) semantic check (i.e. if said type is valid in the use context), rather than needing to examine the insides for this [note: still has some "substitution"-like semantics e.g. clocking check is still obtained from "inside"... since we are only making type visible not all other characteristics ... ] of said arg. We need a strict type interpretation because casting is not allowed in pass by ref i.e. a sequence is not a property, one can use 1647 routines if s/he needs to know the true nature. Same strict typing for basic data types e.g. bit has to match with a bit actual etc... To type cast, one must create a new var or untyped seq/prop shell that does the casting and pass a reference to that or just use untyped passing to begin with -- state/elaborate all of this in 1549. ** With this understanding we can clean up then move forward on 1549, and use it as basis for other proposals e.g. 1) we can delve more into lvar passing as args in light of decisions above i.e. it becomes clear that 1667 needs a keyword (TBD) to do pass by value of the lvar. 2) 1601: use "void" instead of "implicit": Meaning it has no type i.e. fall back on "substitution" semantics 3) Create new issue for access visibility (naming, scoping etc...) of local var in (lvar's seq/prop) instantiating context. Thx. -Bassam.Received on Tue Nov 14 14:14:27 2006
This archive was generated by hypermail 2.1.8 : Tue Nov 14 2006 - 14:14:57 PST