> "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
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 03:48 PM 9/4/2001 -0400, Uri Guttman wrote:
> > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >
> > DS> Ah. I've always wanted to do that with tied
> hashes. Okay, even
> > DS> more reason to pass the data in! (We're going to
> en
>> 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
At 03:48 PM 9/4/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
> DS> Ah. I've always wanted to do that with tied hashes. Okay, even
> DS> more reason to pass the data in! (We're going to end up with a
> DS> WANT register by the time we're done...)
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
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Ah. I've always wanted to do that with tied hashes. Okay, even
DS> more reason to pass the data in! (We're going to end up with a
DS> WANT register by the time we're done...)
that is not a bad idea. we could allocate a PMC registe
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I don't buy that there's a higher bar on comprehension,
DS> either. Register machines in general aren't anything at all
DS> new. Granted, lots of folks grew up with the abomination that is
DS> x86 assembly, if they even bothered h
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> The real question, as I see it, is "Should we look
> lexicals up by name?" And the answer is Yes. Larry's
> decreed it, and it makes sense. (I'm half-tempted to
> hack up something to let it be done in perl 5
> --wouldn't take much work)
No need,
From: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> > At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > > Can you see any use
At 08:05 PM 9/4/2001 +0100, Graham Barr wrote:
>On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> > At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > > Can you see any use
On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > Can you see any use of a sub knowing it was called via a method call?
> >
>
At 03:04 PM 9/4/2001 -0400, Uri Guttman wrote:
>for sure. one case i saw recently in c.l.p.m was someone who wanted to
>chain method calls together like this:
>
> $obj->meth1()->meth2() ;
>
>this is easy assuming you return the object in each method call. but he
>ALSO wanted:
>
> $
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
>> Will the subroutine know how it was called? (ie: Through method
>> dispatch or through straightforward symbol table lookup. I'm really
>> hoping the answer to this is 'yes'.) Or
At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > > * Methods get their parameters passed in as a list in
> > > > * PMC register 0, unless we can unambiguously figure
> > > > * out their protot
At 12:38 PM 9/4/2001 +0200, Paolo Molaro wrote:
>I'm not convinced the register machine is the way to go.
Well, neither am I, and I came up with the plan.
Regardless, it's the way we're going to go for now. If it turns out to be a
performance dog then we'll go with a stack-based system. Initial
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > * Methods get their parameters passed in as a list in
> > > * PMC register 0, unless we can unambiguously figure
> > > * out their prototype at compilation time
> >
> >Will the subroutine know how
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 10:53 AM 9/4/2001 +0300, Ariel Scolnicov wrote:
>What happens when I call a prototyped sub with a code ref?
We call the "I've been called with a single list" entry point. One that,
until recently, I hadn't planned on. :)
That, I expect, will extract the elements from the list into registers,
At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > * Methods get their parameters passed in as a list in PMC register 0,
> > * unless we can unambiguously figure out their prototype at
> > * compilation time
>
>Will the subroutine know how it was called? (ie: Through method
>dispatch or through s
At 09:06 AM 9/4/2001 +0100, Simon Cozens wrote:
>On Mon, Sep 03, 2001 at 09:53:11PM -0400, Dan Sugalski wrote:
> > Might as well just promote the things to PMCs and pass in a list of them.
>
>I anticipate that, especially for Perl, in a lot of cases we'll be dealing
>with PMCs more often than the
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
At 01:44 PM 9/4/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > This also makes scope entry and exit costlier, since you need to make a
> > savestack entry and restore, respectively, for each lexical. I don't think
> > it'd be a win, even if closures weren't getting i
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This also makes scope entry and exit costlier, since you need to make a
> savestack entry and restore, respectively, for each lexical. I don't think
> it'd be a win, even if closures weren't getting in your way.
although to be fair, the current run-time
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
On 09/02/01 Simon Cozens wrote:
> =head1 The Software CPU
>
> Like all interpreter systems of its kind, the Parrot interpreter is
> a virtual machine; this is another way of saying that it is a software
> CPU. However, unlike other VMs, the Parrot interpreter is designed to
> more closely mirror
Simon Cozens:
# On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
# > In other words, when you have sub foo {} in your code, it will be
# > assigned an opcode number in the 'private' section. The
# global section
# > is for things that are built-in to Parrot, while the
# private section
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 08:19 PM 9/3/2001 -0400, Sam Tregar wrote:
> >Speaking of soubroutines, what is Parrot's calling conventions? Obviously
> >we're no long in PUSH/POP land...
>
> Up until now, I didn't know, so consider yourself the first to find out. :)
>
> * Intege
On Mon, Sep 03, 2001 at 09:53:11PM -0400, Dan Sugalski wrote:
> Might as well just promote the things to PMCs and pass in a list of them.
I anticipate that, especially for Perl, in a lot of cases we'll be dealing
with PMCs more often than the "scalar" data types.
Simon
On Mon, Sep 03, 2001 at 08:19:32PM -0400, Sam Tregar wrote:
> I'm still not sure I understand why Parrot is doing string ops at all. Do
> all our target languages have identical semantics for string operations?
Nope. But that's OK, because they won't have identical vtables.
(The string vtable f
On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
> In other words, when you have sub foo {} in your code, it will be
> assigned an opcode number in the 'private' section. The global section
> is for things that are built-in to Parrot, while the private section is
> for stuff you write.
On Mon, Sep 03, 2001 at 06:33:19PM -0400, Ken Fox wrote:
> Thanks for the info. If you guys maintain this level of documentation
> as the code develops, Perl 6 will be easy for first-timers to work on.
That's exactly the idea. :)
> > To be more specific about the software CPU, it will contain a
Dan Sugalski <[EMAIL PROTECTED]> writes:
[... stuff I probably don't understand but at least I don't know WHY ...]
> * Integer, String, and Number registers 0-x are used to pass
> * parameters when the compiler calls routines.
>
>
> * PMC registers 0-x are used to pass parameters *if* the sub
72 matches
Mail list logo
