HaloO,
happy new year to Everybody!
Luke Palmer wrote:
Env variables are implicitly passed up through any number of call
frames.
Interesting to note that you imagine the call chain to grow upwards
where I would say 'implicitly passed down'. Nevertheless I would
also think of upwards beeing the positive direction where you find
your CALLER's environment with a $+ twigil var or where the $^ twigiled
vars come from ;)
Since exception handling is about *not* returning but calling your
CALLER's CATCH blocks in the same direction as the environments are
traversed there should be some way of navigating in the opposite
direction of these environments up---or down---to the point where
the error occured. Could this be through $- twigil vars? Or by
having an @ENV array that is indexed in opposite call direction yielding
this frame's %ENV? Thus @ENV[-1] would nicely refer to the actual
error environment. And [EMAIL PROTECTED] tells you how far away you are catching
the error. But this would not allow to retrieve non-exceptional
environmental data frames unless forward indexing from @[EMAIL PROTECTED] and
beyond is supported.
Well, alternative we could have an ERR namespace. BTW, how is the
object data environment handled? Is there a SELF namespace? How much
of that is automagically accessible in CATCH blocks?
$/ was formerly lexical, and making it environmental, first of all,
allows substitutions to be regular functions:
$foo.subst(rx| /(.*?)/ |, { "<it>$1</it>" })
Since .subst could choose bind $/ on behalf of its caller.
Just let me get that right. Whatever $foo contains is stringyfied
and passed as $?SELF to .subst with $_ as a readonly alias?
Then the string is copied into an 'env $/ is rw' inside subst and
handed over to some engine level implementation routine which actually
performs the subtitution. Finally .subst returns the value of this $/.
Well, and for an in-place modification of $foo the call reads
$foo.=subst(...), I guess?
Or was the idea to have three declarations
env $_ is rw = CALLER<$_>; # = $?SELF in methods?
env $/ is rw = CALLER<$/>; # = $?SELF in rules?
env $! is rw = undef; # = CALLER<$!> when exceptional
beeing implicitly in effect at the start of every sub (or block)?
Thus subst could just modify $+/ without disturbing CALLER<$foo>
which might actually be invisible to subst?
It is also aesthetically appealing to have all (three) punctuation
variables being environmental.
And it clears up the strange notion of lexical my-vars :)
I hope lexical now *only* means scanning braces outwards on
the source code level with capturing of state in the (run)time
dimension thrown in for closure creation, lazy evaluation etc.
Talking about lazy evaluation: does it make sense to unify
the global $*IN and $*OUT with lazy evaluation in general?
That is $OUT is where yield writes it value(s) to and $IN
is for retrieving the input. Iteration constructs automatically
stall or resume coroutines as needed.
--
