[sv-ac] 1549 et. al.

From: Bassam Tabbara <Bassam.Tabbara_at_.....>
Date: Tue Nov 14 2006 - 14:14:19 PST
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