Uri Guttman wrote:
> that is good. i wasn't disagreeing with your alternative architecture.
> i was just making sure that the priority was execution over compilation
> speed.
I use a snazzy quintuple-pass object-oriented assembler written
in equal parts spit and string (with a little RecDescent t
Uri Guttman wrote:
> so my point is the the speed of the VM is a separate issue from the ease
> of code generation. an S2S VM would be easier to code generate for but
> may be slower to run. the speed difference is still an open point as dan
> has said. but since his goal is execution speed, that
Uri Guttman wrote:
> and please don't bring in hardware comparisons again. a VM design
> cannot be compared in any way to a hardware design.
I have absolutely no idea what you are talking about. I didn't
say a single thing about hardware. My entire post was simply about
an alternative VM architec
Aaron pointed out:
> But, in terms of constants, it seems to me that there's no
> difference. They both have only one value that is assigned
> when the module/class is parsed.
Well, in *practice* there's no difference, but in their mystical essences,
they're completely different. ;-)
> but from this thread it looks like you and larry are still hammering out
> the details. :) maybe a revision of A3/E3 will be in the offing (like
> larry's retraction of dropping <>).
That's entirely possible. The Perl 6 Ministry of Truth is forever on the
look-out for Revisionist Her
> For a typed subroutine with named parameters, is the declaration syntax
> (sans property declaration) going to be:
>
>'sub' type ident '(' paramlist ')' block
>
> (in, say, Parse::RecDescent)? I'm thinking about how to add subroutines
> to BabyPerl*, and I need to k
On Tue, Oct 30, 2001 at 09:59:49AM +1100, Damian Conway wrote:
>
>> > class Demo {
>> > my $threshold is const = 100;
>>
>> Hmm... is a "my const" the same as an "our const"?
>
> No. 'my' is per-instance; 'our' is per-class.
But, in terms of constants, i
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri wrote:
>> that clears it up. so the key/value named params get converted to scalar
>> args in INIT with the same name. is this in any of the current exegeses?
>> or will sub calls be covered in the apocalyptic future?
DC>
Dan Sugalski wrote:
> What sort of dispatch was your version using, and what sort was
> parrot using in your test?
Parrot used the standard function call dispatcher without bounds
checking.
Kakapo used a threaded dispatcher. There's a pre-processing phase
that does byte code verification because
Uri wrote:
> that clears it up. so the key/value named params get converted to scalar
> args in INIT with the same name. is this in any of the current exegeses?
> or will sub calls be covered in the apocalyptic future?
A3/E3 covered named arguments. The only additional bit here is that
On Mon, Oct 29, 2001 at 05:27:30PM +, David Trusty wrote:
> I would like to request a new feature for perl: The ability to
> attach a perl debugger to a running process.
The DB module gives you the tools to do this sort of thing, though
there is some assembly required for certain very large
For a typed subroutine with named parameters, is the declaration syntax
(sans property declaration) going to be:
'sub' type ident '(' paramlist ')' block
(in, say, Parse::RecDescent)? I'm thinking about how to add subroutines
to BabyPerl*, and I need to know if I'm at least right about
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri asked:
DC> method INIT ( $fooval, $barval) {
>>
>> where is the binding from the keys below to the INIT params? surely (and
>> yes, i am calling you shirley) you don't mean that 'bar' is converted or
>> mapped to $barva
Hi,
I would like to request a new feature for perl: The ability to
attach a perl debugger to a running process.
Also, it would be nice to have the capability to generate a
"dump" (core file) for post-mortem analysis. The perl debugger
could then read the "core" file.
These capabilities would
On Tue, Oct 30, 2001 at 12:27:32PM +1100, Damian Conway wrote:
>> > PS: I'd just like to point out that people gasped in horror when
>> > I presented this idea at YAPC::NA::2001 as part of the
>> > (soon-to-be-released) Klingon binding of Perl. ;-)
>>
>> I'll add my ow
John observed:
> Whatever filter he's running his thoughts through, I'm pretty
> sure it's lossy... ;)
For which mercy you should probably be extremely grateful. ;-)
Damian
> Does this mean that the caller of a multimethod has to know he calls a
> multimethod (as oposed to a regular method). Should not the user of a
> library spared from such implementation details, however sexy they are?
One might well argue the same thing about calling normal subroutines
On 10/29/01 8:44 PM, Dan Sugalski wrote:
> At 12:27 PM 10/30/2001 +1100, Damian Conway wrote:
>> nuch SoH! bIQambogh DaqDaq qaHoH!
>
> The biggest problem with reading mail from Damian is I keep wanting to
> rot13 the thing..
Whatever filter he's running his thoughts through, I'm pretty
sure it'
At 12:27 PM 10/30/2001 +1100, Damian Conway wrote:
>> > PS: I'd just like to point out that people gasped in horror when
>> > I presented this idea at YAPC::NA::2001 as part of the
>> > (soon-to-be-released) Klingon binding of Perl. ;-)
>>
>> I'll add my own, now.
>
>nu
On Mon, 29 Oct 2001, Michael G Schwern wrote:
> On Tue, Oct 30, 2001 at 11:27:39AM +1100, Damian Conway wrote:
> > The $64K question then being: can I call it like so:
> >
> > ($obj1, $obj2)->foo(@args);
>
> Is that merely sugar for:
>
> # errr, $_.foo(@args) ?
> $_->foo(@args) for
> > ($obj1, $obj2)->foo(@args);
>
> Is that merely sugar for:
>
> # errr, $_.foo(@args) ?
> $_->foo(@args) foreach($obj1, $obj2);
No. What you showed would be achieved with either a hyperoperation:
($obj1, $obj2)^.foo(@args);
or a superposition:
>
> > A split between local, marginal, and global registers would be an
> > interesting thing to do, and I can see it making the code more elegant. I
> > worry about it making things more complex, though, especially with us
> > already having multiple register types. (We'd double or triple the num
On Tue, Oct 30, 2001 at 11:27:39AM +1100, Damian Conway wrote:
> The $64K question then being: can I call it like so:
>
> ($obj1, $obj2)->foo(@args);
Is that merely sugar for:
# errr, $_.foo(@args) ?
$_->foo(@args) foreach($obj1, $obj2);
or is there something more interesting goi
> : Um, can we be even more clear? What does the following do?
> :
> : method foo ($atc, $btc: $ctc, $dtc, $etc) {...}
> :
> : Is that an error?
>
> Multimethod dispatch on two objects?
The $64K question then being: can I call it like so:
($obj1, $obj2)->foo(@a
[EMAIL PROTECTED] writes:
: On Tue, Oct 30, 2001 at 09:39:03AM +1100, Damian Conway wrote:
: > Okay, so let's clarify:
: >
: > 1. If you declare a method *with* a colon separator in its parameter
: >list:
: >
: > method foo ($self: $foosrc, $foodest, $etc) {...}
:
: Um,
On Mon, Oct 29, 2001 at 11:20:47PM +, Tom Hughes wrote:
> > 2) But either can support converting directly if it wants.
> The danger is that everybody tries to be clever and support direct
> conversion to and from as many other character sets as possible, which
> leads to lots of duplication.
Y
[EMAIL PROTECTED] writes:
: Larry revealed:
:
:> :method bar($me : *@_) {
:> :...
:> :}
:> :
:> : will use $me instead.
:>
:> That is the approach I currently favor. (Though I'd probably leave
:> out the space in front of the colo
In message <[EMAIL PROTECTED]>
James Mastros <[EMAIL PROTECTED]> wrote:
> > That leaves the third, which is what I have implemented. When looking to
> > transcode from A to B it will first ask A if can it transcode to B and
> > if that fails then it will ask B if it can transcode from A
> > class Demo {
> > my $threshold is const = 100;
>
> Hmm... is a "my const" the same as an "our const"?
No. 'my' is per-instance; 'our' is per-class.
> If so, does this mean that there will be no such thing as a
> C++-style const (constant per in
Sam asked:
> are there any plans in Perl 6 for specifying
> OO <-> RDBMS mapping in the class { } construct? Another way to look at
> this would be adding arbitrary fine grained type constraints to
> attributes, and then tools can be written which examine these constraints
> and
On Tue, Oct 30, 2001 at 09:39:03AM +1100, Damian Conway wrote:
> Okay, so let's clarify:
>
> 1. If you declare a method *with* a colon separator in its parameter
> list:
>
> method foo ($self: $foosrc, $foodest, $etc) {...}
Um, can we be even more clear? What does
> Ick. I don't want to lose the dots that visually distinguish instance
> variables from ordinary lexicals, and simultaneously render the extra
> bracketing and indentation unnecessary. I'd write the above as:
>
> class Demo;
>
> my $.foo is public;
> my $.
Damian Conway:
# Larry revealed:
#
#> :method bar($me : *@_) {
#> :...
#> :}
#> :
#> : will use $me instead.
#>
#> That is the approach I currently favor. (Though I'd
# probably leave
#> out the space in front of the colon.) And it
On Mon, Oct 29, 2001 at 08:32:16PM +, Tom Hughes wrote:
> We have established that the first two will not work because of the
> unicode problem.
Hm. I think instead of requiring Unicode to support everything, we should
require Unicode to support /nothing/. If A and B have no mutual transcodi
At 04:44 PM 10/29/2001 -0500, Ken Fox wrote:
>Well, I've tuned things up a bit. It's now
>hitting 56 mops with the mops.pasm example. Parrot
>turns in 24 mops on the same machine with the same
>compiler options.
Damn. I hate it when things outside my comfort zone end up being faster. :)
>This i
[EMAIL PROTECTED] writes:
: > method INIT ($fooval, $barval)
: > {
: > $.foo = $fooval;
: > $.bar = $barval;
: > }
:
: (sorry, couldn't help fixing the braces... ;)
I don't really care where you put the initial brace, as long as you
outdent the closing brace. My personal brace sty
Brent Dax writes:
: Are we still gonna be able to pick what we call the current instance?
: From previous programming languages, I'm a lot more comfortable with $me
: or $this than $self. (Yeah, it's a little thing, but it's something I
: *liked* about Perl 5's OO--it showed how you had flexibili
On 10/29/01 4:39 PM, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> : On 10/28/01 7:57 PM, Damian Conway wrote:
> : > method foo is lvalue {
> : > return $foo;
> :
> : Any word on automagical creation of these suckers?
>
> Yes, certainly. Didn't I say that a
On 10/29/01 4:38 PM, Larry Wall wrote:
> :> I'm quite curious to see what the initialization syntax will be like.
> :
> : class Demo {
> : my $foo;
> : my $bar;
> :
> : method INIT ( $fooval, $barval) {
> : $foo
A little while back I posted some code that
implemented a storage-to-storage architecture.
It was slow, but I tossed that off as an
implementation detail. Really. It was. :)
Well, I've tuned things up a bit. It's now
hitting 56 mops with the mops.pasm example. Parrot
turns in 24 mops on the same
[EMAIL PROTECTED] writes:
: On 10/28/01 7:57 PM, Damian Conway wrote:
: > method foo is lvalue {
: > return $foo;
:
: Any word on automagical creation of these suckers?
Yes, certainly. Didn't I say that already?
Larry
[EMAIL PROTECTED] writes:
: Aaron wrote:
:
:> Several questions come up.
:>
:>* If $.foo is "like" the Perl5 $self->{foo},
:
: Except (as I'm sure you know) that Perl 6 class instantiations aren't
: hashes, and their attributes aren't hash entries.
Nevertheless, *using* one as a
On Mon, Oct 29, 2001 at 03:15:07PM -0300, Daniel Grunblatt wrote:
> Just to make it clear both of them still need a LOT of work, but I don't
> know to which should I stick.
Just in case anyone wonders what's up with this patch, I'm waiting for
some feedback from others before applying.
--
"So i
In message <[EMAIL PROTECTED]>
"Stephen Howard" <[EMAIL PROTECTED]> wrote:
> right. I had just keyed in on this from Tom's message:
>
> "My code currently allows either set to provide the transform on the
> grounds that otherwise the unicode module would have to either know
> how to c
John Siracusa writes:
> > I think we're due out in reasonably good alpha/beta shape for the summer.
> Heh, the phrase "suitable vague" springs to mind... :)
There's a good reason for that, for why I've tried hard to avoid
giving promises of when things would be ready. Have you seen Apache 2
and
Just to make it clear both of them still need a LOT of work, but I don't
know to which should I stick.
On Mon, 29 Oct 2001, Daniel Grunblatt wrote:
> OK, there is another workaround to make pbc2c.pl work which still uses the
> "goto model" so speed is not affected but it's harder to maintain sin
OK, there is another workaround to make pbc2c.pl work which still uses the
"goto model" so speed is not affected but it's harder to maintain since
it's not as generic as the other one.
Daniel.
Index: pbc2c.pl
=
At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
>Anybody do a gcc-specific "goto *pc" dispatcher
>for Parrot yet? On some architectures it really
>cooks.
That's a good question. There was talk and benchmark numbers from a variety
of different dispatchers.
C'mon folks, kick in the code. I'll weld d
Anybody do a gcc-specific "goto *pc" dispatcher
for Parrot yet? On some architectures it really
cooks.
- Ken
right. I had just keyed in on this from Tom's message:
"My code currently allows either set to provide the transform on the
grounds that otherwise the unicode module would have to either know
how to convert to everything else or from everything else."
...which seemed to posit that Unicode modul
On 10/29/01 1:49 AM, Damian Conway wrote:
>> I guess what I'm really hoping for in Perl 6 is to finally give up my
>> super-simple object base class that does cascading initialization (check)
>> and simple attribute accessor creation (???) when necessary.
>
> Yep.
"I KISS YOU!"
> method foo is
At 02:52 PM 10/29/2001 -0500, Stephen Howard wrote:
>You might consider requiring all character sets be able to convert to Unicode,
That's already a requirement. All character sets must be able to go to or
come from Unicode. They can do others if they want, but it's not required.
(And we'll hav
You might consider requiring all character sets be able to convert to Unicode, and
otherwise only have to know how to convert other
character sets to it's own set.
-Original Message-
From: Tom Hughes [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 29, 2001 02:31 PM
To: [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
>
> >Attached is my first pass at this - it's not fully ready yet but
> >is something for people to cast an eye over before I spend lots of
> >time going down the wro
Dan --
You can also look at section 1.4.1' of
http://www-cs-faculty.stanford.edu/~knuth/fasc1.ps.gz
for another view of subroutine linkage from the upcoming TAOCP.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526)
Dan --
[snip]
> I'll have to snag that manual next time I'm around a good bookstore. I've
> not read it as of yet, and Knuth generally has good things to say.
You can grab PDFs here:
http://link.springer.de/link/service/series/0558/tocs/t1750.htm
Of course, you can also browse around on
At 11:17 AM 10/29/2001 -0500, Gregor N. Purdy wrote:
> > > > *) The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch
> > > and do
> > > > not have to be preserved by the callee
> > >
> > >Still thinking about this... We are reducing the overall number of reg
> > >copies going on by ad
Dan --
> >Looks like I'm going to have to write some real logic in jakoc
> >pretty soon...
>
> Ahhh! The horror! :-)
:)
> Seriously, the conventions are geared towards full-blown compilers with a
> reasonable register ordering module at the very least, which isn't
> unreasonable to expec
At 08:52 AM 10/29/2001 -0500, Gregor N. Purdy wrote:
>The first step I'm going to take is to start putting the arg and
>result counts on the stack, and remove the stack rotation stuff.
Leave the rotate opcode, though. That might come in handy for the
Forth/Scheme/Postscript folks, once we have t
From: Sam Vilain [mailto:[EMAIL PROTECTED]]
>
> It would be a bit like Class::Contract merged with
> Class::Tangram, but if Class::Contract is going into
> the core then it's a feature I'd like to see...
I'd like to see Class::Contract play nicely with Class::Tangram,
Class::Multimethods, etc.
At 08:43 AM 10/29/2001 -0500, Gregor N. Purdy wrote:
>Dan --
>
>On Fri, 2001-10-26 at 16:38, Dan Sugalski wrote:
> > Okay, here are the conventions.
>
>Looks like I'm going to have to write some real logic in jakoc
>pretty soon...
Ahhh! The horror! :-)
Seriously, the conventions are geared t
On Mon, Oct 29, 2001 at 03:03:58PM +, Dave Mitchell wrote:
> As to whether other uses of %MY:: are Good Things, see previous discussions
> ad nauseum on -internals and -language.
Ok, sorry. I didn't mean to resurect an old, tired thread.
I'm sure clear heads will prevail and some precaution
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > If it's an outer-scope lexical, use C{MY}>
>
> Ok, I'm all over the nice new features of Perl6, but darnit,
> "upvar" is one of the primary reasons that TCL is unusable. Please,
> let's not soften the walls of lexical scope. They're there for a
> reaso
On Mon, Oct 29, 2001 at 11:57:47AM +1100, Damian Conway wrote:
> AJS> How would this play with constants?
>
> class Demo {
> my $threshold is const = 100;
Hmm... is a "my const" the same as an "our const"? If so, does this mean
that there will be no such thing as a C++-s
On Mon, Oct 29, 2001 at 11:03:33AM +1100, Damian Conway wrote:
> Brent asked:
>> I assume we're going to recycle 'my' and 'our' to be 'instance' and
>> 'class'--is that correct?
>
> That's what I'm proposing.
This seems wise. Very Perlish.
> If it's an outer-scope lexical, use C{MY}>
Sam --
> > Okay, here are the conventions.
>
> Great. Anyone want to offer up some examples or should I just wait for
> Jako support to see this in action?
I'll be working on making jakoc support the convention, but it may
take a while with my day job duties as they are. If I can get it in
qui
Dan --
On Fri, 2001-10-26 at 16:38, Dan Sugalski wrote:
> Okay, here are the conventions.
Looks like I'm going to have to write some real logic in jakoc
pretty soon...
> *) The callee is responsible for saving and restoring non-scratch registers
Nice for callee since if its work fits into five
On Mon, 29 Oct 2001 11:03:33 +1100 (EST)
Damian Conway <[EMAIL PROTECTED]> wrote:
> The Real Damian is the Damian inside each of us.
> You need to get in touch with your *own* inner Damian.
SETTING: Trendy bar.
DC: Hey, beautiful, how's it going? Say, do you have a little Damian in
you?
Automated smoke report for patch Oct 28 20:00:01 2001 UTC
v0.02 on hpux using cc version B.11.11.02
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:
BD> Uri Guttman:
BD> # DC> class Demo {
BD> # DC> my $foo;
BD> # DC> my $bar;
BD> #
BD> # DC> method INIT ( $fooval, $barval) {
BD> # DC> $fo
70 matches
Mail list logo
