> "Bryan" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
Bryan> The simplest statement is an expression. I'm trying to couch the definition
Bryan> of what composes an expression to exclude 'if', 'while', 'for', etc.
Bryan> Apparently right poorly, at that.
If you treat statement as
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Dan concluded:
>> Certainly doable. Just potentially slow, which is what I'm worried
>> about. Making it not slow has both potential significant complexity
>> and memory usage. If we have to, that's fine. Just want to make
>> s
Damian wrote:
> In other words, everything that Exporter does, only with lexical
> referents not package referents. This in turn gives us the ability to
> easily write proper lexically-scoped modules.
Great! Then we don't need run-time lexical symbol table
frobbing. A BEGIN block can muck with it
At 10:23 PM 9/4/2001 -0400, Ken Fox wrote:
>Efficiency is a real issue! I've got 30,000 lines of *.pm in my
>latest application -- another 40,000 come from CPAN. The lines
>of code run a good deal less, but it's still a pretty big chunk
>of Perl.
>
>The thought of my app suddenly running slower (p
On Tuesday 04 September 2001 10:10 pm, Dan Sugalski wrote:
> At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
> >Yes, this is akin to redeclaring every lexical variable every time you
> >introduce a new scope. Not pretty, I know. But if you want run-time
> >semantics with compile-time resolu
Damian wrote:
> Dan wept:
>> I knew there was something bugging me about this.
>>
>> Allowing lexically scoped subs to spring into existence (and
>> variables, for that matter) will probably slow down sub and
>> variable access, since we can't safely resolve at compile time wh
At 12:00 PM 9/5/2001 +1100, Damian Conway wrote:
>Dan concluded:
>
>> Certainly doable. Just potentially slow, which is what I'm worried
>> about. Making it not slow has both potential significant complexity
>> and memory usage. If we have to, that's fine. Just want to make
>> sure
At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
>Yes, this is akin to redeclaring every lexical variable every time you
>introduce a new scope. Not pretty, I know. But if you want run-time
>semantics with compile-time resolution
That is exactly what it is, alas. If we allow lexicals to
=head1 TITLE
API for the Perl 6 debugger.
=head1 VERSION
1.1
=head2 CURRENT
Maintainer: David Storrs ([EMAIL PROTECTED])
Class: Internals
PDD Number: ?
Version: 1
Status: Developing
Last Modified: August 18, 2001
PDD Format: 1
Language: English
=head2
On Tuesday 04 September 2001 09:09 pm, Damian Conway wrote:
> A C is a statement, just as an C or a C is a statement.
Okay, then I simply need to rethink/redefine how I'm defining a statement,
(which is currently in terms of the statement separator).
--
Bryan C. Warnock
[EMAIL PROTECTED]
Bryan asked:
> > That would be:
> >
> > given ( $a ) {
> > when /a/ : { foo($a); goto BAR }
> > when /b/ : { ... }
> > BAR: when /c/ : { ... }
> > ...
> > }
>
> If they were statements, wouldn't that be:
>
On Tuesday 04 September 2001 08:32 pm, Dan Sugalski wrote:
> Absolutely nothing. The issue is speed. Looking back by name is, well,
> slow. The speed advantage that lexicals have is that we know both what pad
> a variable lives in and what offset in the pad it's living at. We don't
> have to do an
Dan concluded:
> Certainly doable. Just potentially slow, which is what I'm worried
> about. Making it not slow has both potential significant complexity
> and memory usage. If we have to, that's fine. Just want to make
> sure the cost is known before the decision's made. :)
I rather
At 07:24 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
>On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
> > Ah, but what people will want is:
> >
> >my $x = "foo\n";
> >{
> > my $x = "bar\n";
> > delete $MY::{'$x'};
> > print $x;
> >}
> >
> > to print foo. That's
At 10:34 AM 9/5/2001 +1100, Damian Conway wrote:
>Dan wept:
>
>> I knew there was something bugging me about this.
>>
>> Allowing lexically scoped subs to spring into existence (and
>> variables, for that matter) will probably slow down sub and
>> variable access, since we can
Dan wept:
> I knew there was something bugging me about this.
>
> Allowing lexically scoped subs to spring into existence (and
> variables, for that matter) will probably slow down sub and
> variable access, since we can't safely resolve at compile time what
> variable or sub
Dan sighed:
> >I don't understand why you think that's particularly wormy?
>
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things g
On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things get tricky. Though I suppose we could
> put some sort of pl
At 10:04 AM 9/5/2001 +1100, Damian Conway wrote:
>Dan wrote:
>Why not C? It merely requires that the internals equivalent of:
[Snippy]
>I don't understand why you think that's particularly wormy?
Ah, but what people will want is:
my $x = "foo\n";
{
my $x = "bar\n";
delete $MY::
On Tuesday 04 September 2001 06:39 pm, Damian Conway wrote:
> the "expr" is more likely to be a "parameter_specification".
Urk. I'll wait for the movie, I think.
>> >> 6. [ LABEL: ] expr if expr;
>> >> 7. [ LABEL: ] expr unless expr;
>> >
>> > I'm not at all sure modif
Bryan wrote:
> > > Er, scratch this. Blows up if the sub isn't prototyped. A much
> > > *better* way is to make the prototype of any sub a property
> > > (trait) of that sub. We can always query for a property.
> >
> > This is possible now:
> > $foo = sub ($) { print "hello wor
Dan wrote:
> At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> >
> >So deleting it
> >would remove it from the scratchpad of &incr. But I would guess that
> >future calls to &incr would have to autovify $x in the scratchpad and
> >start incrementing it from 0. I.e., ignorin
>> What about if the symbol doesn't exist in the caller's scope
>> and the caller is not in the process of being compiled? Can
>> the new symbol be ignored since there obviously isn't any
>> code in the caller's scope referring to a lexical with that
>> name?
>
> No. Because so
Dave Mitchell asked:
> If there is to be a %MY, how does its semantics pan out?
That's %MY::. The colons are part of the name.
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
Bryan wrote:
> > C and C
>
> [ LABEL: ]
> try { block }
> [ [ catch [ ( expr ) ] { block } ] ... ]
the "expr" is more likely to be a "parameter_specification".
> >> Conditional Statement Modifiers
> >>
> >> 6. [ LABEL: ] expr if expr;
> >>
At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
>The main uses are (surprise):
>
> * introducing lexically scoped subroutines into a caller's scope
I knew there was something bugging me about this.
Allowing lexically scoped subs to spring into existence (and variables, for
that matter)
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Thank-you. But I have to contend with the inflation of expectations.
DC> Last year I wow'd them with simple quantum physics. This year, I needed
DC> a quantum cellular automaton simulation of molecular thermodynamics
DC> written
Ken wrote:
> Damian Conway wrote:
> > It would seem *very* odd to allow every symbol table *except*
> > %MY:: to be accessed at run-time.
>
> Well, yeah, that's true. How about we make it really
> simple and don't allow any modifications at run-time to
> any symbol table?
At 01:27 PM 9/4/2001 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > It'll probably be something like "Here's the function name. Here's the
> > parameters. Do The Right Thing." I don't think there's much need for
> > cleverness on the part of the interface. The actual dispatch code could b
At 03:54 PM 9/4/2001 -0400, Michael G Schwern wrote:
>Ummm... there should be no *language* reason why we can't override
>inline methods. It's purely an internal distinction.
I'm not so much thinking about inline methods as inline subs.
>The unfortunate problem with saying "inline methods canno
On Tuesday 04 September 2001 11:17 am, Garrett Goebel wrote:
> > Er, scratch this. Blows up if the sub isn't prototyped. A
> > much *better* way is to make the prototype of any sub a
> > property (trait) of that sub. We can always query for a
> > property.
>
> This is possible now:
>
> $foo = s
David L. Nicol wrote:
> How about some nice introductory links for MOP theory? The
> above-linked post is also the only time I recall seeing aspect
> theory mentioned in here either. Someone explained aspectJ to
> me at a PM meeting and it sounded like a sure recipe for
> completely impossible A
On Tue, Sep 04, 2001 at 09:30:19AM -0700, Hong Zhang wrote:
> > This is the only real reason I've seen to allow final. (And it's not a bad
>
> > reason, honestly, though not necessarily one appropriate in all cases) It
> > does allow a fair amount of optimization to be done, which can be
> > es
Me wrote:
> I found just one relevant occurence of 'mop' in perl6-all archives:
>
> http://www.mail-archive.com/perl6-all@perl.org/msg10432.html
>
> And not a single reply...
>
> I'd really like to see what Dan / lisp folks have to say about mops
> and perl6...
How about some nice introductor
Says Dave Mitchell:
> Closures ... can also be dangerous and counter-intuitive, espcially to
> the uninitiated. For example, how many people could say what the
> following should output, with and without $x commented out, and why:
>
> {
> my $x = "bar";
> sub foo {
> # $x # <-
Dan Sugalski wrote:
> It'll probably be something like "Here's the function name. Here's the
> parameters. Do The Right Thing." I don't think there's much need for
> cleverness on the part of the interface. The actual dispatch code could be
> nasty, but that's someone else's problem. :)
>
>
At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > sub Bar::import {
> > my %m = caller(1).{MY}; # or whatever
> > delete %m{'$x'};
> > }
>
>hmm... when:
>
>{ my $x = 1; sub incr {$x++} }
>
>is compiled, the $x++ in &incr refers to the lexical $x. So deleting it
>would remove it from t
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
>
> If there is to be a %MY, how does its semantics pan out?
>
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
> }
IMO: Sets the value of the lexical $x i
If there is to be a %MY, how does its semantics pan out?
for example, what (if anything) do the following do:
sub Foo::import {
my %m = caller(1).{MY}; # or whatever
%m{'$x'} = 1;
}
sub Bar::import {
my %m = caller(1).{MY}; # or whatever
delete %m{'$x'};
}
sub f {
my $x =
At 09:30 AM 9/4/2001 -0700, Hong Zhang wrote:
> > >The only good justification I've heard for "final" is as a directive
> > >for optimization. If you declare a variable to be of a final type, then
> > >the compiler (JIT, or whatever) can resolve method dispatch at
> > >compile-time. If it is not
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Can we have an example of why you want run-time
> symbol table manipulation?
How about being able to dump and restore subroutines and closures along with
their lexical environment?
Perhaps this next example doesn't have to fall under the runtime cate
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Dan revealed:
>> That's easy--you slip the pumpking or internals designer a 10-spot.
>> Amazing what it'll do... :)
DC> And how do you think I got five of my modules into the 5.8 core???
i heard it was blackmail. you got a hol
> >The only good justification I've heard for "final" is as a directive
> >for optimization. If you declare a variable to be of a final type, then
> >the compiler (JIT, or whatever) can resolve method dispatch at
> >compile-time. If it is not final, then the compiler can make no such
> >assumptio
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
>
> On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
> > The third value is a "peek" value. Do the runtime
> > checking, but don't do any magic variable stuff. As a
> > matter of fact, don't run any user-code at all. Simply
> > re
On Tuesday 04 September 2001 12:27 am, Damian Conway wrote:
> C and C
[ LABEL: ]
try { block }
[ [ catch [ ( expr ) ] { block } ] ... ]
?
>
> (C is not nearly so certain.)
>
>> Conditional Statement Modifiers
>>
>> 6. [ LABEL: ] expr if expr;
>> 7. [ LABEL: ] expr unl
On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
> The third value is a "peek" value. Do the runtime checking, but don't do
> any magic variable stuff. As a matter of fact, don't run any user-code at
> all. Simply return a true or false value if the arguments *would* match.
> (This
46 matches
Mail list logo
