John Williams writes:
> On Sun, 5 Sep 2004, Matt Diephouse wrote:
>
> > Don't say -1st is the "first from last". If last is the opposite of
> > first, I would expect 1st to mean "first from first," which would
> > mean the second. Say "first from the end".
>
> It matches up with perl5 C<$array[-
On Sun, 5 Sep 2004, Matt Diephouse wrote:
> Am I the only one that thinks that -1st should return the last element
> in an array under the nth scheme? 1st should mean the first element.
> -1st should mean the first element of the reversed array.
>
> Don't say -1st is the "first from last". If last
On Sat, Sep 04, 2004 at 09:47:29AM +0200, Leopold Toetsch wrote:
: Honestly I don't see the point why all "normal" array usage should be
: slowed down just for the sake of some rare usage patterns.
Another possibility is that .[] always forces the "normal" view of an
array as 0-based, and if you w
On Mon, Sep 06, 2004 at 10:13:56AM +0200, Leopold Toetsch wrote:
: A different vtable implies some kind of a derived class. The question
: is, if an "of shape" or "is shape" already causes a new class of
: arrayish objects.
: The question probably is: how much of this class code is done directly
:
[EMAIL PROTECTED] (John Siracusa) writes:
> Don't you think it's preferable to temp-expanding and compiling at runtime?
Not if it's slower, no. The choice was made not to go with bytecode because
of a deficiency in Perl. If that deficiency wasn't there, then sure, go
with bytecode.
But you're mis
On Mon, Aug 30, 2004 at 12:17:57PM -0500, Abhijit Mahabal wrote:
> Another example to clarify what I am getting at:
>
> Role Log2File [: $filename] { method do_the_logging {...}; ... }
> Role Log2Email [: $address ] { method do_the_logging {...}; ... }
> Role Log2Tk[: $widget ] { method do
(not on the list, please Cc me in replies.)
On Sun, Sep 05, 2004 at 08:49:20PM -0400, John Siracusa wrote:
> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
> and runs. It's closest to item #2 in my feature list, but it's something
> very different than compiling down to
On Mon, Sep 06, 2004 at 12:28:16PM -0400, John Siracusa wrote:
> Hm, well, features of the perl6 executable itself aren't really fodder for
> the parrot lists (are they?)...although I forget where they've been
> discussed in the past. Anyway, the long-suffering internals guys are still
> hashing
On 9/6/04 12:21 PM, Nicholas Clark wrote:
>> I think packaging has the same characteristics. But unlike CPAN, packaging
>> does require some minimum amount of core support to meet what I consider to
>> be the minimum standard of elegance.
>
> I think that this is true. I'm not sure what the minim
On 9/6/04 12:13 PM, Nicholas Clark wrote:
> On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote:
>> Finally, platform independent execution of any packaged or precompiled
>> single file will *require* cooperation (core support) from the perl
>> executable itself. PAR is neat, but it does
On Sun, Sep 05, 2004 at 10:40:24AM -0400, John Siracusa wrote:
> 3. The single-file, platform independent, non-source executable (P6exe).
> This is bytecode or some other platform neutral representation of the SDoF.
> I just don't see how to do this at all without core support. (Well, I
> suppose
On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote:
> Finally, platform independent execution of any packaged or precompiled
> single file will *require* cooperation (core support) from the perl
> executable itself. PAR is neat, but it doesn't even match up that well with
> JAR, which
On 9/6/04 3:48 AM, Simon Cozens wrote:
> [EMAIL PROTECTED] (John Siracusa) writes:
>> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
>> and runs.
>
> It *could* do this, but loading bytecode in Perl 5 is slower than loading
> and compiling source, so there's not really m
On Mon, 6 Sep 2004 11:48:59 +, Herbert Snorrason <[EMAIL PROTECTED]> wrote:
> As it stands, though, perl6-internals isn't about perl, but Parrot ...
> so of the two lists, language is arguably more appropriate...
perl6-internals is about perl the implementation (which is parrot).
perl6-languag
The Perl 6 Summary for the week ending 2004-09-03
Another week, a free weekend, and still I haven't started writing the
summary until Monday. Still, I don't actually start at college 'til next
week, so that's all right then.
We start with perl6-internals.
Compile op with return
"Joe Gottman" <[EMAIL PROTECTED]> writes:
> In perl 6, the statement
>
> @foo = (1.. 5) ;
>
> is equivalent to
>
> @foo = (1, 2, 3, 4, 5);
>
>
>
> Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? I know you can
> go
>
> @foo = reverse (1
On Sat, 2004-09-04 at 17:59, John Siracusa wrote:
> Actually, the other day I was thinking about how I tend to create any useful
> perl program that I plan to distribute in the form of a big, monolithic
> script. Take the distribution out of the equation and I'd write a series of
> generic module
As it stands, though, perl6-internals isn't about perl, but Parrot ...
so of the two lists, language is arguably more appropriate...
On Sun, 5 Sep 2004 22:37:04 -0400, Matt Diephouse <[EMAIL PROTECTED]> wrote:
> I may be completely off base here, but I think this whole discussion
> would be bette
Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 04, 2004 at 09:47:29AM +0200, Leopold Toetsch wrote:
>: Honestly I don't see the point why all "normal" array usage should be
>: slowed down just for the sake of some rare usage patterns.
> Does it have to? Couldn't it have a different vtable?
[EMAIL PROTECTED] (John Siracusa) writes:
> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
> and runs.
It *could* do this, but loading bytecode in Perl 5 is slower than loading
and compiling source, so there's not really much point. What's so magic
about bytecode, anyway
20 matches
Mail list logo
