Re: What's up with %MY?
On Friday 07 September 2001 12:56 am, Ken Fox wrote: > "Bryan C. Warnock" wrote: > > Generically speaking, modules aren't going to be running amok and making > > a mess of your current lexical scope - they'll be introducing, possibily > > repointing, and then possibly deleting specific symbols > > How much do you want to pay for this feature? 10% slower code? 50% > slower? Do you want the feature at any price? Which feature? The introduction of new lexicals solely at compile time? We can do that now. I've already demonstrated that this is a solvable problem. Although, admittedly, I wouldn't suggest actually *implementing* my solution, I'm sure someone far more clever than I can come up with a viable one. > > I don't like run-time frobbing of the symbol table. Not even > precise tweaking. ;) I think it's in bad style and inconsistent with > the purpose of lexicals. *But* bad style isn't a good argument > and I wouldn't be pursuing this if it were just a style issue. But it clears up a *lot* of problems that were introduced with local. Much like perlfunc says... You really probably want to be using "my" instead, because "local" isn't what most people think of as "local". See the Private Variables via my() entry in the perlsub manpage for details. Lexicals were never about speed, they were about containership. A lot of Perl's magic and power, however, only work when centered around globals and locals. Muckings there, however, cause true "action at a distance" - what I change here for my benefit may screw something up way over there that I can't see. Allowing this to take place with lexicals reduces those risk factors - do your magic here and only here. > > The trouble lies in running the code. Lexicals used to be known at > compile time. Now they can change practically anywhere. It's like > using C and having *everything* be volatile. Except worse because > you don't even know the address where something is going to be. Lexicals being known at compile-time was a side-effect of the containership. Yes, we want lexicals to be fast. Containing behavior lexically is slightly more important, IMO. If it runs dog-slow, we won't do it. If it runs just a tad slower, we probably should. > > A simple solution would be to allow lexical scope editing at > compile time, but not run-time. Change a BEGIN block's caller() so > that it is the scope being compiled instead of main. This achieves > the majority of the benefits (lexical imports at compile time) > without any downside. Nope. Think 'require'. > > There are two other things that are easy to add. If the > compiler knew in advance which lexicals might dynamically change, > it could generate better code and not slow everything down. A > trait called ":volatile" or something. IMHO this would also > show intent to the people reading the code that something funny > might happen to the variable. (Macros or compile-time injected > lexicals could declare the :volatile trait, so I would imagine > that some pretty interesting packages could still be written.) Except that magic will probably be going on behind the scenes, so you don't know it's magically. Otherwise, you'd just assign whatever it was to the lexical variable and be done with it -- Bryan C. Warnock [EMAIL PROTECTED]
Re: What's up with %MY?
At 12:13 AM 9/7/2001 -0400, Ken Fox wrote: >Damian Conway wrote: > > "3, 1, 3" is the correct answer. > >That's what I thought. Dan's not going to be happy. ;) Well, it means a fetch by pad entry rather than use of a cached PMC pointer, but that's OK by me. I have a solution for this that I'm perfectly comfortable with, so I'm fine. Once we've worked out how things should behave, then we can get on with implementing it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl, the new generation
On Fri 11 May 2001 16:31, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Fri, May 11, 2001 at 01:55:42AM +0100, Graham Barr wrote:
> > On Thu, May 10, 2001 at 07:40:04PM -0500, Jarkko Hietaniemi wrote:
> > > By far most of my use of typeglobs is making aliases, and then mostly
> > > for code:
> > >
> > > *color = \&colour;
> >
> > I would say that probably the most common use now for typeglobs is
> > from the IO:: modules. Which are created with gensym so they are
> > anonymous.
>
> Personally, I use typeglobs mostly to autogenerate repetitive methods
> without an autoloader:
>
> *method = $closure;
>
> but this should definately have a direct analogy in Perl 6 so I'm not
> worried.
I use it to check if formats exist, since there is no other way to do so
(except maybe an eval that dies :():
if (defined *{$::{$fmt}}{FORMAT}) {
local $~ = $fmt;
write;
}
but for perl6 it doesn't matter, cause formats will die anyway (even without
an eval :)
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 629 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: LangSpec: Statements and Blocks
will the iterator variable be available in map, grep, join...etc...
I was also wondering if the join syntax be extended in a way that it can
support preffix and suffix... what i have in mind ... not necesary but :
#pair
join ($prefix => $suffix), @ary;
so :
my $select = join (qq{} => ''), @ary;
or is better to stay like this :
my $select;
map { $select .= qq{$_} } @ary;
=
iVAN
[EMAIL PROTECTED]
=
Re: LangSpec: Statements and Blocks
On Friday 07 September 2001 03:22 pm, raptor wrote:
> will the iterator variable be available in map, grep, join...etc...
Iterators haven't been defined yet, so it's hard to tell.
For map and grep, it's certainly feasible, depending on their implementation
- although neither are truly iterators.
For join, I don't see where you would access it.
>
> I was also wondering if the join syntax be extended in a way that it can
> support preffix and suffix... what i have in mind ... not necesary but :
> #pair
> join ($prefix => $suffix), @ary;
>
> so :
> my $select = join (qq{} => ''), @ary;
That's not really joining.
>
> or is better to stay like this :
> my $select;
> map { $select .= qq{$_} } @ary;
Definitely.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Fri, Sep 07, 2001 at 10:22:49PM +0300, raptor wrote:
> I was also wondering if the join syntax be extended in a way that it can
> support preffix and suffix... what i have in mind ... not necesary but :
> #pair
> join ($prefix => $suffix), @ary;
>
> so :
> my $select = join (qq{} => ''), @ary;
That's a map if ever I saw one :-)
> or is better to stay like this :
> my $select;
> map { $select .= qq{$_} } @ary;
or
$select = join '', map { qq{$_} } @ary;
or
$select .= qq{$_} for @ary;
or when Perl gets reduce()
$select = reduce {
$_[0].qq{$_}
} '', @ary;
or whatever makes you happy.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: An overview of the Parrot interpreter
At 10:47 PM 9/6/2001 +0200, Paolo Molaro wrote: >On 09/06/01 Dan Sugalski wrote: > > Then I'm impressed. I expect you've done some things that I haven't yet. > >The only optimizations that interpreter had, were computed goto and >allocating the eval stack with alloca() instead of malloc(). Doesn't this really get in the way of threading? You'll chew up great gobs of system stack, and that's a scarce resource when running with threads. >Of course, now it's slower, because I implemented the full semantics required >by IL code (the biggest slowdown came from having to consider >argments and local vars of any arbitrary size; making the alu opcodes >work for any data type slowed it down by 10 % only): but the parrot >interpreter doesn't need to deal with that kind of stuff that slows >down interpretation big time. Still, it's about 2x faster than perl5 >on the same benchmarks, though I haven't tried to optimize the new code, yet. Well, we should have code ready for checkout on Monday--I'm really interested to see what our respective speeds are with low-level operations. > > Also, while I have numbers for Parrot, I do *not* have comparable numbers > > for Perl 5, since there isn't any equivalence there. By next week we'll > > have a basic interpreter you can build so we can see how it stacks up > > against Mono. > >See above, I expect it to be faster, at least handling the low-level stuff >since I hope you're not going to add int8, uint8 etc, type handling. Gack, no. Ints are native sized. If people want shorter ints, they can use full-blown variables. > > >Yep, but for many things there is an overlap. As for the dynamic language > > >issue, I'd like the ActiveState people that worked on perl <-> .net > > >integration to share their knowledge on the issues involved. > > > > That one was easy. They embedded a perl interpreter into the .NET > execution > > engine as foreign code and passed any perl to be executed straight to the > > perl interpreter. > >I think they worked also on outputting IL bytecode... Yep, but that version was slower. Dick Hardt snagged me at TPC this year (I think I spent most of my non-speaking time being pinned to a table or bench by folks with Things To Say... :) and made a .NET pitch. They were going with the translation to .net but switched to embedding perl. It was a lot faster. (Brad Kuhn had a paper on translating perl to java bytecode and he had lots of trouble, but for different reasons) > > completely counter to what .NET (and java, for that matter) wants to do. > > Including runtime compilation from source and runtime redefinition of > > functions. (Not to mention things like per-object runtime changeable > > multimethod dispatch, which just makes my head hurt) > >Naah, with the reflection support you can create types and methods on the >fly, the rest can probably be done with a couple of ad-hoc opcodes. Maybe. It'd be nice if that's true, though spitting out to .Net's a secondary issue for me--a working interpreter's first. Once we get the interpreter fast is when we (well, someone at least--probably not me) work on emitting .net or jvm code instead of perl bytecode. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
parrot question
While waiting for Parrot (dammit, I took the wrong week off), I've been scanning the various documents and samples which have been floating around on the list. Is there a document describing Parrot syntax yet? Or is that a "will be released on monday" thing as well? Brian Wheeler [EMAIL PROTECTED]
Re: parrot question
At 03:10 PM 9/7/2001 -0500, Brian Wheeler wrote: >While waiting for Parrot (dammit, I took the wrong week off), I've been >scanning the various documents and samples which have been floating >around on the list. Is there a document describing Parrot syntax yet? >Or is that a "will be released on monday" thing as well? You mean the assembly language? Yep. I sent out a version of the PDD a while back, I think. There have been some changes, so I'll send a new version in a bit. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: language agnosticism and internal naming
On Thu, Sep 06, 2001 at 04:55:49PM -0700, Benjamin Stuhl wrote:
> I had a thought this morning on funtion/struct/global
> prefixes for Parrot. If we really plan to also run
> Python/Ruby/whatever on it, it does not look good for the
> entire API to be prefixed with "perl_". We really (IMHO)
> ought to pick something else so that we don't give people a
> convenient target for FUD.
Like this, you mean?
STRING_VTABLE Parrot_string_vtable[enc_max];
...
IV
string_compute_strlen(STRING *s) {
return (s->strlen = (Parrot_string_vtable[s->encoding].compute_strlen)(s));
}
:)
Simon
PDD 6: Parrot Assembly Language
Here's the assembly PDD. Changes to it to come, of course. ---Cut Here-- =head1 TITLE Parrot assembly language =head1 VERSION =head2 CURRENT Maintainer: Dan Sugalski Class: Internals PDD Number: 6 Version: 1.2 Status: Developing Last Modified: 25 August 2001 PDD Format: 1 Language:English =head2 HISTORY =over 4 =item Version 1.2 August 25, 2001 =item Version 1.1 August 8, 2001 =item version 1 None. First version =back =head1 CHANGES =over 4 =item Version 1.2 We have an interpreter now! Yay! (Okay, a simple one, but still...) Changes made to reflect that. =item Version 1.1 =over 4 =item * Added in object =item * Changed remnants of "perl" to "Parrot" =item * Branch destination may be integer constant =item * Added L section =back =item Version 1.0 None. First version =back =head1 ABSTRACT This PDD describes the format of Parrot's bytecode assembly language. =head1 DESCRIPTION Parrot's's bytecode can be thought of as a form of machine language for a virtual super CISC machine. It makes sense, then, to define an assembly language for it for those people who may need to generate bytecode directly, rather than indirectly via the perl (or any other) language. =head1 IMPLEMENTATION Parrot opcodes take the format of: code destination, dest_key, source1, source1_key, source2, source2_key Conditional branches take the format: code boolean, bool_key, true_dest, false_dest The key parameters are optional, and may be either an integer or a string. If either is passed they are associated with the parameter to their left, and are assumed to be either an array/list entry number, or a hash key. Any time a source or destination can be a PMC register, there may be a key. Destinations for conditional branches are an integer offset from the current PC. All registers have a type prefix of P, S, I, or N, for PMC, string, integer, and number respectively. =head1 Assembly syntax All assembly opcodes contain only ASCII lowercase letters and the underscore. Upper case names are reserved for assembler directives. Labels all end with a colon. They may have ASCII letters, numbers, and underscores in them. Labels that begin with a dollar sign (the only valid spot in a label a dollar sign can appear) are private to the subroutine they appear in. Namespaces are noted with the NAMESPACE directive. It takes a single parameter, the name of the namespace. Multilevel namespaces are supported, and the namespaces should be double-colon separated. Subroutine names are noted with the SUB directive. It takes a single parameter, the name of the subroutine, which is added to the namespace's symbol table. Sub names may be any valid Unicode alphanumeric character and the underscore. String and integer constants don't need to be put in a separate =head1 OPCODE LIST In the following list, there may be multiple (but unlisted) versions of an opcode. If an opcode takes a register that might be keyed, the keyed version of the opcode has a _k suffix. If an opcode might take multiple types of registers for a single parameter, the opcode function really has a _x suffix, where x is either P, S, I, or N, depending on whether a PMC, string, integer, or numeric register is involved. The suffix isn't necessary (though not an error) as the assembler can intuit the information from the code. In those cases where an opcode can take several types of registers, and more than one of the sources or destinations are of variable type, then the register is passed in extended format. An extended format register number is of the form: register_number | register_type where register_type is 0x100, 0x200, 0x400, or 0x800 for PMC, string, integer, or number respectively. So N19 would be 0x413. B: Instructions tagged with a * will call a vtable method to handle the instruction if used on PMC registers. In all cases, the letters x, y, and z refer to register numbers. The letter t refers to a generic register (P, S, I, or N). A lowercase p, s, i, or n means either a register or constant of the appropriate type (PMC, string, integer, or number) =head2 Control flow The control flow opcodes check conditions and manage program flow. =over 4 =item if tx, X, Y Check register tx. (Px, Sx, Ix, or Nx) If true, branch by X, otherwise branch by Y. =item jump tx Jump to the address held in register x (Px, Sx, or Ix). =item branch tx Branch forward or backward by the amount in register x. (X may be either Ix, Nx, or Px) Branch offset may also be an integer constant. =back =head2 Data manipulation These ops handle manipulating the data in registers =over 4 =item iton Nx, Iy Copy the integer value from register y to the numeric register x. =item ntoi Ix, Ny Copy the number from register y to register x. Copy is truncated, and may be capped if it is too large or small for an integer. =item tostring Sx, ty, Iz Take the value in register
Defeating variable-width encodings
A thought I had: if variable-width encodings are so difficult because it's hard to index into them by character, why don't we break them up ourselves? +PV---+ +strchunk-+-+ +strchunk-+-+ |string |-->|the quick brown fox jumped ov|>+-->|er the lazy dog |/| |... | +-+-+ +-+-+ Now, if we want to substr($str, 40, 1), we can skip the first chunk. (32 was a number I picked out of the air; other numbers may be better.) This avoids the possible huge overheads of other linked-list approaches while also avoiding some of the linear scanning that would otherwise be required to index into the string. As far as things with lvalue substr()...we could fudge that number a bit and allow strchunks to be a little more or less than 32, as long as they know their size. Then, whey you scan, you just add up the number of characters in each chunk until you overshoot. That makes scanning a bit slower, but not much. (We'd probably also want the string to rebalance itself periodically, but that's a different story.) An alternate approach would be to remember how far into the string you have to index to get to certain points in the string. (For the purpose of this part of the document, a 'byte' is a codepoint and a 'character' is an abstract character.) For example: +PV---+ |string |-->"the quick brown fox jumped over the lazy dog" |length 44| |bytes 44| |half 22| |quar 11| |threeq 33| |... | Although in this example the string is normal ASCII, consider what we would have if we replaced the 'o' in 'brown' and the 'a' in 'lazy' with two-byte characters (represented by a doubled letter): +PV---+ |string |-->"the quick broown fox jumped over the laazy dog" |length 44| |bytes 46| |half 23| |quar 11| |threeq 34| |... | Now, on a call like substr($str, 36, 1) we can skip all the way to byte 34--which we know represents character number 33--and count from there. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Re: An overview of the Parrot interpreter [speed]
hi, I see that it was mentioned that Perl5 is fast than Java, Python etc... and was wondering is there any comparison how-much, if ? and if why ? and if we know the reason can we exploit it further ... and similar... And does really Perl6 will be faster. how much u expect ? Thanx = iVAN [EMAIL PROTECTED] =
Re: An overview of the Parrot interpreter [speed]
At 10:30 PM 9/7/2001 +0300, raptor wrote: >I see that it was mentioned that Perl5 is fast than Java, Python etc... and >was wondering is there any comparison how-much, if ? and if why ? and if we >know the reason can we exploit it further ... and similar... >And does really Perl6 will be faster. how much u expect ? This stuff is all very benchmark-specific. Doing low-level things, like integer math operations, Java's faster. Doing higher-level stuff, like regexes or things with hash variables, perl's faster. The more time a perl program spends inside its "fat" opcodes, the more likely perl is to win over java/python/tcl/ruby/etc. Competent C programmers can beat perl every time. (Actually *finding* a competent C programmer is left as an exercise for the reader... :) There are a variety of benchmarks scattered around the 'net. Google or Northern Light should find them for you. How valid they are is something else entirely. There are benchmarks in a variety of books, but I don't have cites handy. Tom Christiansen did for a while, but I think they've fallen off his website, and they were getting kind of stale anyway. As for perl 6 vs perl 5, that's reasonably easy. We benchmark things on perl 5.004_04 and 6.x, and see who wins. If 6 doesn't, we find out why and speed it up. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: An overview of the Parrot interpreter [speed]
On Friday 07 September 2001 05:38 pm, Dan Sugalski wrote: > > As for perl 6 vs perl 5, that's reasonably easy. We benchmark things on > perl 5.004_04 and 6.x, and see who wins. If 6 doesn't, we find out why and > speed it up. :) 5.004? (Is that where the big drop-off begins?) You are going to take into consideration where Perl 6 might take a little longer just because it has to do something 5.004 doesn't, right? (Like Unicode Everywhere). -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Final, no really, Final draft: Conventions and Guidelines for Perl Source Code
>>How about something a little more explicit than XXX, like TODO or FIXME? > Some syntax-highlighting editors highlight "XXX". Let's use that feature. Which ones? emacs doesn't seem to do it by default. > And how can you get more explicit than XXX, anyway? Funny, but I still think TODO or FIXME makes more sense. >>>In function definitions, the name starts in column 0, with the >>>return type on the previous line >>Eww. Why do we want this again? > 1) Dicky C compilers Which ones? > 2) Ease of parsing. (By our own tools that is, not by cc) int foo() is easier than int foo() ? By the tinyest amount. Is that really worth it for what is probably harder to human read. >>>/*=for api apiname entityname[,entityname..] flags (TBC) >>>comments >>>*/ >>> >>This is perl5ish syntax. Has there been thought about a different syntax here? >> > > I'd prefer to go the other way, and just have POD everywhere. At the moment, > I'm spec'ing out the API for various functions by embedding POD in C comments; > I can then just run perldoc on a plain old C file, and I've got an API document. Sure, POD everywhere, but lets make it POD6 with a little less whitespace and the other improvments that might come down the pipe. Limiting ourselves to POD5 will cause uglyness. -R
Re: An overview of the Parrot interpreter [speed]
At 05:41 PM 9/7/2001 -0400, Bryan C. Warnock wrote: >On Friday 07 September 2001 05:38 pm, Dan Sugalski wrote: > > > > As for perl 6 vs perl 5, that's reasonably easy. We benchmark things on > > perl 5.004_04 and 6.x, and see who wins. If 6 doesn't, we find out why and > > speed it up. :) > >5.004? (Is that where the big drop-off begins?) Dunno. I came into perl with 5.004 (Well, 5.003_92, but close enough) and that's the earliest perl it's feasible to benchmark, as it's the earliest perl that's really safe. The numbers go downhill from 5.004_04 to 5.005 to 5.6. (Try a 5.004_04 build against a 5.6.1 build with any of the thread options. Yowtch!) >You are going to take into consideration where Perl 6 might take a little >longer just because it has to do something 5.004 doesn't, right? No. If the task is the same, then I don't care what perl 6 needs to do. If we decide all integers need to be 128 bits that's fine, but we still had damn well be faster than perl 5. If perl 6 needs to do more under the hood, it better do it fast enough to not matter. >(Like >Unicode Everywhere). Who's doing that? We're keeping things in native format as much as we can. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: An overview of the Parrot interpreter [speed]
On Friday 07 September 2001 05:51 pm, Dan Sugalski wrote: > >(Like > >Unicode Everywhere). > > Who's doing that? We're keeping things in native format as much as we can. If one of our stated goals is Unicode support (even for the source itself - that's what I meant by "everywhere": source, input, output), we're going to be a little more hindered than if we didn't have to worry about it at all, no? Or will you only compare Granny Smiths with Granny Smiths? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: An overview of the Parrot interpreter [speed]
At 05:54 PM 9/7/2001 -0400, Bryan C. Warnock wrote: >On Friday 07 September 2001 05:51 pm, Dan Sugalski wrote: > > >(Like > > >Unicode Everywhere). > > > > Who's doing that? We're keeping things in native format as much as we can. > >If one of our stated goals is Unicode support (even for the source itself - >that's what I meant by "everywhere": source, input, output), we're going to >be a little more hindered than if we didn't have to worry about it at all, >no? No. We don't want Unicode everywhere because: *) Conversion to Unicode is sometimes lossy *) Conversion back out of Unicode is sometimes lossy *) Converting when we know how to work on the underlying string data is wasted cycles *) Lots of folks using non-7-bit ASCII have perfectly adequate character sets with defined operations, so why should they have to use Unicode if they don't need it? Unicode's sort of a greatest-common-multiple character set. We'll use it if we need to, but it's no panacea. (Unfortunately) >Or will you only compare Granny Smiths with Granny Smiths? If you compare, say, a Shift-JIS string to a Big5/traditional string, they'll probably both end up both converting to Unicode and the result compared. (Assuming that neither the Big5/traditional nor the Shift-JIS string library knows how to convert to the other losslessly) And a plain string comparison for gt/lt is less straightforward than you might think... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
On Friday 07 September 2001 01:30 pm, Dan Sugalski wrote: > In all cases, the letters x, y, and z refer to register numbers. The > letter t refers to a generic register (P, S, I, or N). A lowercase p, > s, i, or n means either a register or constant of the appropriate type > (PMC, string, integer, or number) How many registers are the going to be per type? Unlimited? -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain
Re: PDD 6: Parrot Assembly Language
On Friday 07 September 2001 07:21 pm, Matthew Cline wrote: > On Friday 07 September 2001 01:30 pm, Dan Sugalski wrote: > > In all cases, the letters x, y, and z refer to register numbers. The > > letter t refers to a generic register (P, S, I, or N). A lowercase p, > > s, i, or n means either a register or constant of the appropriate type > > (PMC, string, integer, or number) > > How many registers are the going to be per type? Unlimited? Currently 32 per. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: language agnosticism and internal naming
On Fri, Sep 07, 2001 at 10:32:42AM -0400, Dan Sugalski wrote: > Simon's going there already. We should fix the docs up, though. (I have a > bunch of PDDs to update and submit. I think they're going to go into the > CVS repository too, once it's fully operational, so I don't lose track of > things) Chuck 'em in. The rate I'm going, I'll assimilate them into the docs I'm writing, which can probably become new PDDs. Simon
Re: language agnosticism and internal naming
At 04:55 PM 9/6/2001 -0700, Benjamin Stuhl wrote: >I had a thought this morning on funtion/struct/global >prefixes for Parrot. If we really plan to also run >Python/Ruby/whatever on it, it does not look good for the >entire API to be prefixed with "perl_". We really (IMHO) >ought to pick something else so that we don't give people a >convenient target for FUD. > >For lack of anything better, I propose "par_" for >functions. We might stll be able to get away with "PL_ " >for globals (Parrot Library?), but I doubt it. Simon's going there already. We should fix the docs up, though. (I have a bunch of PDDs to update and submit. I think they're going to go into the CVS repository too, once it's fully operational, so I don't lose track of things) >Just something else to consider. (But hopefully a topic >that won't make Dan's brain hurt any more than it probably >does. :-) Nah, this stuff's easy. Anything I can fix with a "perl -pi -e" and still fit in an 80 character terminal line's OK with me. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: An overview of the Parrot interpreter [speed]
Actually there were some tests done, can't recall where now, though by a trusted source. I will be digging it up in my email and emailing it to the list. There were a few languages tested including Perl, C, C++, Java (can't remember if Python was there). Perl came in in second place after C. Yes, that's faster than C++. Again, I totally understand that a lot of it is dependent on what's being tested, which I couldn't recall at this time either, though I believe to recall that it was some general stuff. Ilya > -Original Message- > From: raptor [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 07, 2001 3:30 PM > To: [EMAIL PROTECTED] > Subject: Re: An overview of the Parrot interpreter [speed] > > > hi, > > I see that it was mentioned that Perl5 is fast than Java, Python > etc... and > was wondering is there any comparison how-much, if ? and if why ? > and if we > know the reason can we exploit it further ... and similar... > And does really Perl6 will be faster. how much u expect ? > Thanx > = > iVAN > [EMAIL PROTECTED] > =
Re: An overview of the Parrot interpreter [speed]
On Friday 07 September 2001 11:08 pm, Sterin, Ilya wrote: > Actually there were some tests done, can't recall where now, though by a > trusted source. I will be digging it up in my email and emailing it to the > list. There were a few languages tested including Perl, C, C++, Java > (can't remember if Python was there). Perl came in in second place after > C. Yes, that's faster than C++. Again, I totally understand that a lot > of it is dependent on what's being tested, which I couldn't recall at this > time either, though I believe to recall that it was some general stuff. IIRC, Dr. Dobb's reported a similar (if not the same) test a couple years ago. However, they speculated a known bug in the MFC for the C++ test is what caused it to be slower. They were doing textual processing, and C, Perl, and awk, I believe, were pretty quick, with the problematic C++ in the middle, and Java significantly slower. But that was then... -- Bryan C. Warnock [EMAIL PROTECTED]
Second public parrot demo
Hey, folks. I'm going to be giving the world's second public parrot demo at this month's Boston.pm meeting. It's Tuesday the 11th at 7 PM, give or take, at the Boston.com building in (who'd've thought) Boston. :) If you're interested in coming, make sure to RSVP to Ronald Kimball, <[EMAIL PROTECTED]>. (Don't RSVP me! I'll lose the note!) Directions at http://boston.pm.org/where.html, or http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=320+Congress+St&city=Boston&state=MA&zip=02210-1238&country=us&slt=42.351300&sln=-71.049600&mag=9&cs=9&name=Boston.com (barring word-wrap) And yes, we'll have details of how to get the current parrot source yourself next monday, so you can play along at home! :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
