Re: [sv-bc] Mantis 1602: task/function inout arg defaults - draft proposal

----- Non-member submission from Greg Jaxon -----
Date: Thu, 16 Aug 2007 12:43:47 -0500

Bresticker, Shalom wrote:

>     [SB] My proposal essentially preserves that original wording. The
>     original said,
> 
>     "The expression is evaluated in the scope containing the
>     subroutine declaration."
> 
>     My proposal has the wording,
> 
>     "the default expression is evaluated in the scope containing the
>     subroutine declaration, not in the scope containing the subroutine
>     call."
> 
>      
> 
>     The additional sentence that I added that you refer to is,
> 
>     "the call is treated as though the default had been written
>     explicitly in the subroutine call."
> 
>      
> 
>     The reason I added that sentence is that the phrase, "the
expression
>     is evaluated" gives the impression that its value is evaluated and
>     its value is used. That makes sense for an input, but not for an
>     ouput, inout, or even a const ref.

Shalom,

   That new wording seems too strong to me, though.  If a complex
expression for the default argument /had/ been written explicitly in the
subroutine call, the names it uses /wouldn't/ be resolved in the scope
that declared the subroutine.
Imagine a vector with a dynamic subscript variable.   It is my
impression that
such a default expression becomes an "lvalue-thunk" (to mix metaphors
from C and Algol):  i.e. it is compiled into an access path dependent
upon variable names from the scope where the subroutine is declared, but
is used in sequential contexts multiple times.  Each call site evaluates
the access path to copy -in and/or -out to a call-site-specific storage
location.  Notice that the thunk and its memory references has to count
as part of the execution body of the subroutine for the purposes of, for
example, determining whether it stays within the set of imports allowed
by a modport that has provided the subroutine.

   I know your wording tries to convey this latter point: how the
default "evaluates" once per dynamic call site (just like an
explicitly-written argument would).  You're also right to avoid the term
"value" to describe what I just called an "lvalue-thunk".  For those
trying to word-smith this difficult subject, let me try saying it all in
friendlier terms:

  The default expression for a subroutine formal argument passes as a
"call-by-name" argument from the declaration of the subroutine to each
actual call-site.  When a call-site omits the actual argument whose
corresponding formal argument has a default, this "call-by-name"
argument is evaluated to produce either a value or an lvalue (sometimes
called a "descriptor").  Within the default expression, names are
already resolved in the scope of the subroutine declaration, but their
current values are fetched in the course of normal sequential
elaboration of the call-site.

Disclaimers all around - the above semantics are still in proposal
stage; anything could happen by the time this appears in products...
Greg Jaxon


--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.