RE: context across function calls

The Working group has had discussions on this issues and the consensus
was that functions should not inherit the dynamic context (this will be
part of section 3.1.4 on function calls). The upcoming working drafts
should reflect that. If you find that the wording in the document does
not answer your concern, please let us know.

Best regards
Michael


> -----Original Message-----
> From: Per Bothner [mailto:per@bothner.com]
> Sent: Thursday, August 15, 2002 12:26 PM
> To: Michael Rys
> Cc: Damien Fisher; www-ql@w3.org
> Subject: Re: context across function calls
> 
> Michael Rys wrote:
> > Since functions may be compiled outside of the context where they
are
> > called, currently the function definition below would not pick up
the
> > dynamic context. Instead I would expect such a function to raise a
> > compilation error about that there is not enough context information
> > provided.
> 
> Yes, the 'context size' and 'context position' *values* are part of
the
> dynamic context, not available to the compiler.  However, the
position()
> and last() functions are part of the static context, visible to a
> compiler.  Your argument is like say that the expression '10 + $x'
> cannot be compiled because the compiler does not have enough context
> information to do the addition at compile time.
> 
> > Passing implicit contexts is dangerous and should not be encouraged
by
> > the language since it makes the function partially dynamically
scoped
> > (talk to old APL programmers why dynamic scoped functions are a pain
to
> > debug).
> 
> However, the informal language language specification does define
> 'context size' and 'context position' to be part of the dynamic
context.
> 
> > Instead rewrite your function to take the position and last as
argument:
> 
> Right, no one is arguing that my sample program is good style or
cannot
> be re-written.  The point is that the specification documents appear
to
> be inconsistent, in a rather important area, and no-one on the
committee
> has acknowledged that this is an issue that must be resolved.
> --
> 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/

Received on Thursday, 15 August 2002 15:54:21 UTC