Re: RFC 339 (v1) caller->eval BLOCK
At 18:43 -0500 2000/10/02, David L. Nicol wrote:
>Hmm. C could be implemented in terms of the rfc 340 C like
>so:
>
> $scope_out_here = with;
> if ($ints) {
> with $scope_out_here {use integer}
> };
>
>C is about subroutine calls.
Interesting! I have a few questions (meandering thoughts) though
The example in the RFC gives:
sub A{
my $A = shift;
return with;
};
$context1 = A(3);
print "$context1"; # something like CONTEXT(0XF0GD0G)
print "$A" with $context1; # prints 3
with $context1{print "$A"}; # same thing
This implies that &A is now something akin to a closure, correct?
That is to say, the meaning of C becomes changed by the
presence of C so that $A is something in between a
lexical scoped to &A and a lexical scoped around &A ({ my $A; sub A
{} }). $A is held in existence by the presence of the context
object. Presumably $A would 'go out of scope' and be destroyed at
the same time as the associated context object? This worries me, but
I admit it's neat ;)
What is more worrying to me is this: with a C pragma, you
can only go up /your/ scope. Consider this:
package Nasty;
my $context;
{
package Unsuspecting_Package;
$context = with;
}
use integer with $context;
Spooky action at a distance to be sure! Also, integer (and others)
is a compile time issue. Using C can be easily (it would
appear) implemented for compile-time since it's merely another
pragma. On the other hand, C strikes me as more of a run-time
beast. (at this point, I'm not sure if I have any idea of what I'm
talking about, so excuse me if this has digressed into rambling :)
So I like the idea of C, but am not sure it is compeltely
suitable for invoking pragmata such as integer.
.greg
--
"Push to test."
"Release to detonate."
Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD
>XML, on the other hand, uses & as the escaping mechanism, helping >a reader sort-out deeply-nested escapings. ... >POD has a good advantage in that it's design allows for it to >embed well into code. If documentation is to be alongside >code, a direction to consider is to have the Perl >program be an XML document itself, with the code inside of it, >between designated tags. This would allow for the entire >Perl program/document to be rendered in a unified manner, using >one tool, and conforming to one meta-language, XML. By making a Perl program an XML document, the programmer is forced to read the XML. It should be noted that XML isn't supposed to be read by a person - it is meant to be read by a computer. The W3C document "XML in 10 points" states this as point three. From http://www.w3.org/XML/1999/XML-in-10-points : >XML files are text files, as I said above, but even less than HTML >are they meant to be read by humans. They are text files, because >that allows experts (such as programmers) to more easily debug >applications, and in emergencies, they can use a simple text editor >to fix a broken XML file. .greg -- Greg Williams| If you wish to live a life free from sorrow, Cnation | think of what is going to happen as if it had [EMAIL PROTECTED] | already happened.
Re: RFC 339 (v1) caller->eval BLOCK
On Sep 30 2000 22:38:58, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
>=head1 ABSTRACT
>
>C is extended to allow complete access to the "call frame" of
>the current subroutine call.
>
would this be better suited by the previously proposed (i'm not sure for perl6 though)
C pragma? Looks like Nathan Wiger has already proposed a 'scope' pragma in
RFC 64, but it does not cover this functionality as far as I know...
as I remember, the C pragma, when used, would simply act as if the
enclosing scope were not in place, enabling such things as:
if ($ints) {
no scope;
use integer;
}
Tom Christiansen brought up the idea on p5p at:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00863.html
.greg
