hes and pipelines (avoid those branches, man!),
are globals Good or Evil (or Chaotic Neutral...).
- someone would need to write this.
Waddayafink? If people dont object, I'll begin drafting.
* Dave Mitchell, Senior Technical Consultant
* Fretwell-Downing Informatics Ltd, UK. [EMAIL PROT
Dan Sugalski <[EMAIL PROTECTED]> doodled:
> At 11:09 PM 3/23/2001 +, Simon Cozens wrote:
> >For instance, chr() will produce Unicode codepoints. But you can pretend that
> >they're ASCII codepoints, it's only the EBCDIC folk that'll get hurt. I hope
> >and suspect there'll be an equivalent of
Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> >Either run pod through a pod puller before the C preprocessor gets to
> >the code, or figure out a set of macros that can quote and ignore pod.
> >
> >The second is Yet Another Halting Problem so we go with the first?
> >
> >Which means a little prog
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 02:58 PM 3/26/2001 +0100, Dave Mitchell wrote:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> > > Perhaps we could teach pod that /* was alias for =pod
> > > and */ an alias for =cut ?
> >
> >or
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Somewhat tangentially: this reminds me of a message a week ago or so
> (can't find it anymore in my inbox) which proposed writing C (or C++)
> code for Perl 6 so that "modern CPU architectures are happy" (no
> pipeline stalls because of "if"-s, etc.)
I'm in the middle of drafting the PDD on coding conventions,
and in the bit on naming things, I've run into the Perl 5 stuff
that does
#define foo Perl_foo
etc.
Its not clear to me whether this is for backwards compatibility or for
convenience (or for something even more fiendish related to per
Coming back to the original question of whether its okay to have
convenience macros foo() to save typing perl_foo(),
I'm going to have one more go at arguing against it
We're all agreed that externally linked entities (functions and global
vars) need a perl_ prefix to avoid name clashes when
=head2 CURRENT
Maintainer: Dave Mitchell <[EMAIL PROTECTED]>
Class: Internals
PDD Number: TBD
Version: 1
Status: Proposed
Last Modified: 7 May 2001
PDD Format: 1
Language: English
=head2 HISTORY
Based on an earlier draft which covered only code comments.
=head1 CHANGES
> I see nothing about namespacing, e.g. Perl_
All entities should be prefixed with the name of the subsystem they appear
in, eg C, C. They should be further prefixed
with the word 'perl' if they have external visibility or linkage,
eg
perlpmc_foo()
struct perlio_bar
typedef struct perlio_bar
Larry Wall <[EMAIL PROTECTED]> wrote:
> Dave Mitchell writes:
> : | my personal pet peeve: death to dSP and friends !!
...
> I think that's silly. You misuse a variable that requires an auto, the
> compile dies, that's all. And macros can be very useful for an abstr
And there was me thinking the shiny ball must be a camel dropping
Just a quick obeservation:
Given the radicalness of the changes suggested by apo 2, I think it's
fair to say that the proportion of Perl 5 code that will run unchanged
on a Perl 6 interpreter will be heading into single-figure percentages.
While I personally think this will be price well worth pa
Since we all seem to be agreed that macros that Do Strange Things are evil,
but are a necessary evil in certain extensibility situations,
and since Larry choked on my choice of naming scheme for macros
which declare variables for you, here's a slighly more modest proposal:
=item *
A macro that m
> Briefly: We want the Perl 6 runtime to be an equivalent of the Microsoft
> CLR, so that if you can somehow get bytecode onto it - from whatever
> language - you can run it. So we've got some bytecode that perl can run.
> Now think about what B::Deparse does.
I knew the intention was to go the
Damian Conway <[EMAIL PROTECTED]> wrote
>> > >my $a is true = 0; # variable property
>> > >my $a = 0 is true; # variable property
>> > >my ($a) = 0 is true;# value property
>> >
>> > Wow. Totally ETOOCONFUSING.
>
> Okay, folks, here's the current conundrum:
>
> Should Parrot be a register or stack-based system, and if a register-based
> one, should we go with typed registers?
For low-level assembly, registers are important because using them
avoids memory accesses. For high-level perl 6 bytecode, I supp
> If anyone wants to do some really useful work, they can scout through
> sv.c, av.c and hv.c, and summarise the functions that Perl 5 expects to
> be able to perform on scalars, arrays and hashes.
I've been meaning for a while to sit down and thoroughly go through sv.c
to understand and document
> I've been meaning for a while to sit down and thoroughly go through sv.c
> to understand and document it. So, consider sv.c 'grabbed'; if no-one's
> done av.c and sv.c in the meantime, I may get round to them too.
^
hv.c of course.
A. C. Yardley" <[EMAIL PROTECTED]> wrote:
>How about you take sv.c? And I'll take av.c and hv.c? Sound good?
okay, its a deal!
Simon Cozens <[EMAIL PROTECTED]> wrote:
> ACY's taking a look into this too, so you may want to co-ordinate to avoid
> clashing. I've also told him what I'd like: some
or speed first, then tweak to reclaim some space
+while not affecting performance.
---
and the PDD itself:
---
=head1 TITLE
Conventions and Guidelines for
> > "K&R" style for indenting control constructs: ie the closing C<}> should
> > line up with the opening C etc.
> >
> > =item *
> >
> > When a conditional spans multiple lines, the opening brace must line up
> > with the "if" or "while", or be at the end-of-line otherwise.
>
> I certainly will
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> I don't like push/pop - they imply a lot of stack limit checking word-by-word
> when it is less overhead for compiler to analyse the needs of whole
basic-block
> check-for/make-space-on the stack _once_ then just address it.
There's no reason why you
> >the op code is stored in network endian order and the interpreter will
> >always build a 16 bit int from the 2 bytes.
>
> Not network. Native. We can put a marker at the beginning of any bytecode
> stream, and provide an endian-swapper. That way we're always running at
> platform optimal enco
Larry Wall <[EMAIL PROTECTED]> wrote:
> It may certainly be valuable to (not) think of it that way, but just
> don't be surprised if the regex folks come along and borrow a lot of
> your opcodes to make things that look like (in C):
>
>while (s < send && isdigit(*s)) s++;
This is the bit th
Simon Cozens <[EMAIL PROTECTED]> opined:
> On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> > This is the bit that scares me about unifying perl ops and regex ops:
> > can we really unify them without taking a performance hit?
>
> Coupl'a things:
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, May 23, 2001 at 06:08:52PM +0100, Simon Cozens wrote:
> > ACY's taking a look into this too, so you may want to co-ordinate to avoid
> > clashing. I've also told him what I'd like: something like this:
> >
> > Scalar
> > Strings
> > Ch
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:00 PM 6/13/2001 +0100, Dave Mitchell wrote:
> >should we abandon vtables (ie arrays of fn pointers indexed by op),
> >and just have a single hander function per type which has the op as an arg?
>
> Are you talking vta
mad thought for the day:
I was thinking back to the earlier discusions on opcode dispatch,
and the fact that some people thought that a big switch was as good as,
or possibly faster than a dispatch table. Which led me to think...
should we abandon vtables (ie arrays of fn pointers indexed by op)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:43 PM 6/19/2001 -0500, David L. Nicol wrote:
> > set $B to copy-on-write mode, so future changes to $B do not
> > affect $A
>
> The one problem with copy-on-write is that, if we implement it in software,
> we end up paying the price to che
Graham Barr <[EMAIL PROTECTED]> wrote:
> Ouch. I have quite often had applications that would use several hundred MB
> now. If I would need double that, then that is going to hurt. I am not
> familiar with copying collector GC, does anyone have a pointer to any
> papers etc.
The basic operation o
> Out of morbid curiosity (since I'm working on documentation), given the
> program that the following program generates:
>
> #!/your/path/to/perl -w# perl 5.6.1
> my @l = ('a' .. 'g');
> my $my = 0;
>
> for my $v (@l) {
>my @a = map { "\$$v .= '$_'" } @l;
>$a[$my++] = "my $a[$my]"
Bart Lateur <[EMAIL PROTECTED]> wrote:
> This came up on comp.lang.perl.misc once, and Ilya Z. then wrote, IIRC,
> that there's no reason why the DLL (if I may call it this way) should
> have a name identical to the module name. His example was that on his
> port, for OS/2, he added a (machine gen
Back in the mists of time (May 29th), I solicited comments on my second
draft of the deeply thrilling "Conventions and Guidelines for Perl
Source Code". There were various contributions, but having more interesting
things to do [watching paint dry etc - Ed], I never got round to incorporating
them
Here's the final draft. Please consider it formally submitted; someone
(Dan? Ask? Adam?) needs to assign it a number, please.
Dave.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell <[EMAIL PROTECTED]&g
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > =item *
> >
> > Uncuddled elses: ie avoid C<} else {>
>
> Does this mean avoid:
>
> if (...) {
> ...
> } else {
> ...
> }
>
> and instead use:
>
> if (...) {
> ...
> }
> else
> {
> ...
> }
>
> If my interpretation of what it means is cor
I think then we are all agreed that the format is
/* comment */
if (...) {
...
}
/* comment */
else {
...
}
with mandatory {}s.
For completeness, we should also include chained else-ifs; I think the
following is reasonably uncontroversial:
/* comment */
if (...) {
...
}
/* comment
Just thought I'd run the following up the flagpole to see if anyone
laughs at it
Closures are useful, powerful things, but they 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
Piers Cawley <[EMAIL PROTECTED]> wrote:
> > {
> > my $x = "bar";
> > sub foo {
> > # $x # <- uncommenting this line changes the outcome
> > return sub {$x};
> > }
> > }
> > print foo()->();
>
> Well, I would expect it to output 'foo' on both occasions, and I'm
> more than a l
Paul Johnson <[EMAIL PROTECTED]> wrote:
> Actually, foo() is not a closure. A closure is an anonymous subroutine
> and foo() clearly has a name.
Damain's definition of a closure includes named subs:
"In Perl, a closure is just a subroutine that refers to one or more lexical
variables declared o
> I guess you missed where I suggested that putting "my" on that
> declaration is also counter-sensical, not to mention redundant.
> "my" implies a brand-spanking-new lexical variable attached
> to this very scope. The semantics of "outer" (or "closed"...)
> can be defined to imply a lexical var
Paul Johnson <[EMAIL PROTECTED]> wrote:
> Try changing your original example from
>
> sub foo {
>
> to
>
> *foo = sub {
>
> and you'll see that everything works "as expected".
add a BEGIN so that instantion happens at the same time that a named
sub would be:
BEGIN { * foo = sub { } }
John Porter <[EMAIL PROTECTED]> wrote:
> Dave Mitchell wrote:
> > I think closures are a lot harder (or at least subtler) than people
> > think,
>
> It's hard for me to agree with you, because I've never had *any*
> problems with closures. (And yes, I us
Okay, this really, really *really* the final draft.
can I have a PDD number, please Dan?
The only change since last is the stuff about if/else layout.
Dave M.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell <[EM
Ken Fox <[EMAIL PROTECTED]> wrote:
> We must be very careful not to confuse "closure" with "Perl's
> current implementation of closure". You've stumbled onto a bug in
> Perl, not discovered a feature of closures. Perl's "closures"
> were horribly buggy until release 5.004. (Thanks Chip!)
Er, no i
Ken Fox <[EMAIL PROTECTED]> wrote:
> You really need to learn what a closure is. There's a very nice book
> called "Structure and Interpretation of Computer Programs" that can
> give you a deep understanding. **
Quite possibly I do. Anyway, I've now got the book on order :-)
> You're speaking in
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Firstly, a magic number is presented to identify the bytecode file as
> Parrot code.
Hopefully this is followed by a header that has a version number and
lots of useful stuff like flags and offsets and things, just like wot
real object files have :-)
> N
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
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 =
Dan Sugalski <[EMAIL PROTECTED]> wrote
> >my $x = 1;
> >{
> > my $x = 2;
> > delete $MY::{'$x'};
> > print $x;
> > $mysub = sub {$x};
> >}
> >
> >print $mysub->();
> >
> >People seem agreed that print $x should do the equivalent of
> > throw "lexical '$x' no longer in scope
Garrett Goebel <[EMAIL PROTECTED]> wrote
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > sub Foo::import {
> > my %m = caller(1).{MY}; # or whatever
> > %m{'$x'} = 1;
> > }
...
> > sub f {
> > my $x = 9;
> >
can I just clarify something about delete:
my $x = 1;
{
my $x = 2;
delete $MY::{'$x'};
print $x;
$mysub = sub {$x};
}
print $mysub->();
People seem agreed that print $x should do the equivalent of
throw "lexical '$x' no longer in scope"
rather than printing 1, but what s
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 September 2001 06:16 am, Dave Mitchell wrote:
> > One further worry of mine concerns the action of %MY:: on unintroduced
> > variables (especially the action of delete).
> >
> > my $x = 100
"Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> Consider it like, oh, PATH and executables:
> `perl` will search PATH and execute the first perl found, but 'rm perl' will
> not. It would only remove a perl in my current scope..., er, directory.
But surely %MY:: allows you to access/manipulate v
One further worry of mine concerns the action of %MY:: on unintroduced
variables (especially the action of delete).
my $x = 100;
{
my $x = (%MY::{'$x'} = \200, $x+1);
print "inner=$x, ";
}
print "outer=$x";
I'm guessing this prints inner=201, outer=200
As for
my $x = 50;
{
my $x =
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 11:05:37AM +0100, Dave Mitchell wrote:
> > I'm trying to get my head round the relationship between pad lexicals,
> > pad tmps, and registers (if any).
>
> It's exactly the same as the r
whoops, forgot to CC the list
- Begin Forwarded Message -
Date: Thu, 6 Sep 2001 14:32:19 +0100 (BST)
From: Dave Mitchell
Subject: Re: pads and lexicals
To: [EMAIL PROTECTED]
Content-MD5: iVd18ng5xfzBBgJHSPdShg==
Ken Fox <[EMAIL PROTECTED]> wrote:
> Dave
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:35:53PM +0100, Dave Mitchell wrote:
> > The Perl equivalent $a = $a + $a*$b requires a
> > temporary PMC to store the intermediate result ($a*$b)
>
> Probably a temporary INT or NUM register, in fact
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > of a pad full of tmp targets, each hardcoded as the target for individual
> &
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> Where do they come from? Leave a plate of milk and cookies on your back
> porch and the Temp PMC Gnomes will bring them. :)
Ah, things are starting to make sense!
> ne
I'm trying to get my head round the relationship between pad lexicals,
pad tmps, and registers (if any).
The PMC registers are just a way of allowing the the address of a PMC to
be passed to an op, and possibly remembered for soonish reuse, right?
So presumably we still have the equivalent of a
Here's a list of what any Perl 6 implementation of lexicals must be able to
cope with (barring additions from future apocalyses). Can anyone think of
anything else?
>From Perl 5:
* multiple instances of the same variable name within different scopes
of the same sub
* The notion of intr
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 September 2001 08:53 am, Dave Mitchell wrote:
> > But surely %MY:: allows you to access/manipulate variables that are in
> > scope, not just variables are defined in the current scope, ie
> >
>
Robert Spier <[EMAIL PROTECTED]> wrote
> >>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 explici
Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> Erk, we seem to be muddling around in that great grey area between what is
> Parrot and what is Perl.
Yes, which leads me on to think...
(With my "maintainer of the Coding PDD" hat on)
Presumably we have to decide what bits of code have a Parrot_
On Sun, Nov 13, 2005 at 11:58:39AM -1000, Joshua Hoblitt wrote:
> I started a thread about this a couple of weeks ago. I really think
> that bison 1.75c should be the minimum requirement.
Note also that bison < 1.24 has licencing issues, in that the generated
output files are GPLed.
--
Art is a
On Tue, Nov 22, 2005 at 09:32:37AM -0800, Chip Salzenberg wrote:
> On Tue, Nov 22, 2005 at 03:28:02PM +0100, Leopold Toetsch wrote:
> > sub do_add3 {
> > my $a = $_[0];
> > sub add3 {
> > $a + 3;
> > }
> > add3();
> > }
>
> What Perl 5 does with that case is just a plain ol
On Wed, Nov 15, 2006 at 11:17:57PM +, Nicholas Clark wrote:
> I thought that allowing undef in my ($a, undef, $b) came in around 5.004ish,
> but I can't find it in perldelta, and I don't have a version compiled to
> test with (or any quick way to compile them, given that pretty much only
> AIX
On Sat, Jan 27, 2007 at 10:23:03AM +0100, Carl Mäsak wrote:
> my $foo;
> # ...later in the same scope...
> my $foo; # illegal Perl5, legal Perl6
No, that's perfectly legal in perl5; it just generates a warning:
use warnings;
my $x = 1;
my $f1 = sub { $x };
my $x = 2;
my $f2
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
> Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
On Wed, May 29, 2002 at 03:23:41PM -0400, Dan Sugalski wrote:
> At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
> >On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
> >> Parrot has to handle signals, such as SIGSEGV.
> >
> >That's the one signal I
> *) Expect POSIX's dead-stupid mutexes to magically unlock
Hmmm, are we confident that we can write exception handling and stack
rollback code that will always clean up mutexes?
--
"There's something wrong with our bloody ships today, Chatfield."
Admiral Beatty at the Battle of Jutland, 31st M
Aplogies if this has already been discussed, but I haven't been following
p6i too closely of late (the lure of being allowed to mess with 5.7.3
has been too strong :-)
Anyway, I presume that the Perl6 theading model will be like Perl 5
ithreads - that is to say, each thread has its own interprete
On Tue, Jun 04, 2002 at 10:43:02AM +0100, Simon Cozens wrote:
> (Please CC me on replies)
>
> I don't often express many opinions on Perl 6 these days, but I feel I have to
> warn people about what I see as a potential loss of direction.
>
> I'm becoming somewhat disillusioned with Perl 6 these
On Tue, Jun 11, 2002 at 11:31:37AM -0400, Dan Sugalski wrote:
> We'll find out with A6 whether we do coroutines and continuations as
> part of the core perl. If not, well, python does the first and ruby
> the second, so it's all good in there.
Does anyone feel like giving a 1 paragraph potted
On Mon, Jun 24, 2002 at 05:21:45PM -0400, David J. Goehrig wrote:
> On Sun, Jun 23, 2002 at 09:50:02PM +0100, Tim Bunce wrote:
> > Much more likely is some kind of wrapper that manages a simple
> > perl5-like run-time environment (stacks, marks, gimme, symboltable
> > etc) plus source-code compati
On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote:
> On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote:
> > Of course, another approach is to embed the existing Perl5 interpreter
> > within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs
On Tue, Jun 25, 2002 at 04:45:37PM +0100, Tim Bunce wrote:
> On Tue, Jun 25, 2002 at 11:35:20AM +0100, Dave Mitchell wrote:
> > On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote:
> > > On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote:
> > > > Of
On Wed, Jul 03, 2002 at 01:23:24PM -0400, Michael G Schwern wrote:
> Hopefully the Cabal [2] can debunk that.
[snip]
> [2] Of which there is none.
and http://www.perlcabal.com/ doesn't exist, right? ;-)
--
"I do not resent critisism, even when, for the sake of emphasis,
it parts for the time w
On Tue, Jul 09, 2002 at 09:50:26PM -0400, Chip Salzenberg wrote:
Based on what I rememeber from the long threads about this,
>3. Is C<%MY> intended to reflect the PAD?
loosely speaking yes.
>
> 3a. If so, how can one distinguish among the e.g. many C
> variables declared within
On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> The place where you'll run into problems in where you have multiple
> variables of the same name at the same level, which you can do in
> perl 5.
can it?
can you give an example?
--
In England there is a special word which means
On Wed, Jul 10, 2002 at 11:57:02PM -0400, Chip Salzenberg wrote:
> According to Dave Mitchell:
> > Based on what I rememeber from the long threads about this,
>
> Ouch. I gather, then, that nntp.perl.org does not house complete list
> archives, or else the discussion was
On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote:
> At 7:18 PM +0100 7/11/02, Dave Mitchell wrote:
> >On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote:
> >> The place where you'll run into problems in where you have multiple
> >> variab
On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
> Nicholas Clark wrote:
> > I was thinking that the metric (x*x + y*y) would be fast to
> > calculate, as that's all we need for ordering.
>
> Point is, it's rather *more* than we need for ordering.
> x + y will suffice.
IIRC, all metr
On Thu, Jul 11, 2002 at 10:37:27PM +0100, Nicholas Clark wrote:
> Is there any specific case where you can't treat
>
> {
> my $foo = 12;
> print $foo;
> my $foo = "ho";
> print $foo;
> }
>
> as
>
> {
> my $foo = 12;
> print $foo;
> {
> my $foo = "ho";
> print $foo;
> }
>
On Thu, Jul 11, 2002 at 08:20:21PM -0700, John Porter wrote:
>
> Dave Mitchell wrote:
> > IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
> > are strongly equivalent, ie they give rise to the *same* ordering.
> > (In the limit as n -> Inf, the metric i
On Sat, Jul 13, 2002 at 03:48:31PM +0100, Nicholas Clark wrote:
> I was working somewhere where the chief technical architect, a very smart
> guy, was far too busy doing stuff to write it down, and also didn't view it
> as a priority as "I don't need to write it down, it's all in my head".
And on
On Wed, Jul 17, 2002 at 01:42:17PM -0700, John Porter wrote:
>
> Andy Dougherty wrote:
> > I think the purpose of the .dev files, as laid out in
> > docs/pdds/pdd07_codinstd.pod, is a reasonable one.
> > Here's an edited excerpt: . . .
>
> (Thanks, Andy.)
>
> Well, given that definition of the
On Wed, Jul 17, 2002 at 11:13:58PM +0100, Nicholas Clark wrote:
> On Wed, Jul 17, 2002 at 10:38:47PM +0100, Dave Mitchell wrote:
> > One of the reasons I used numerical accuracy as an example was because
> > in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhe
On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
> It would be really groovy if that expression could be split with the
> delimiters in place, something like this:
>
>@tokens = split _/[?=*-+]/, $sql, keep=>'all';
>
> and get back an array with these values: ('rank', '=', '?'
On Thu, Aug 01, 2002 at 06:17:11PM -0400, Uri Guttman wrote:
> do these instead:
>
> $bool += 0 ;
> ($x == $y) + 0
or even
$x == $y || 0
--
Never do today what you can put off till tomorrow.
On Fri, Aug 02, 2002 at 11:15:09AM -0600, Jonathan Sillito wrote:
> Could two parallel arrays work? One stores the lexicals (accessed by
> index) and the other stores the names of the lexicals. Then to access a
> lexical by name involves a sequential search through the (probably not
> large) array
In this Brave New World of DOD and GCC, what guarantees (if any)
will we be making at the Perl 6 language level for the timely calling of
object destructors at scope exit?
ie the classic
{ my $fh = IO::File->new(...); }
I know there's been lots of discussion on this over the months,
bu
On Wed, Aug 21, 2002 at 08:25:10PM +0100, I wrote:
> In this Brave New World of DOD and GCC, what guarantees (if any)
s/GCC/GC/
What with PMC, PDD, COW etc, I have TLA on the brain.
:-)
--
Nothing ventured, nothing lost.
On Sun, Aug 25, 2002 at 12:13:36AM -0400, Tanton Gibbs wrote:
> > In my understanding, no. One possible implementation is to set a flag when
> > we create an active_destruction PMC (like IO::File), and perform dod runs
> > at every block close until we don't have any such PMCs left.
>
> I earlier
On Sun, Aug 25, 2002 at 11:16:35AM -0400, Tanton Gibbs wrote:
> > In this case, it is quite likely that many programs will get that flag
> > set. In which case, we'll need to be doing a DOD run at the end of most
> > blocks
>
> I would hope not. The only things which will set this flag are those
On Thu, Sep 05, 2002 at 12:12:52PM +0100, Nicholas Clark wrote:
> On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote:
> > 4) The *only* tools you will need to build parrot are a C compiler
> > environment and either a make tool or a shell
>
> I believe we may be able to get away withou
On Fri, Oct 25, 2002 at 11:27:54AM -0700, Michael Lazzaro wrote:
> &&||!!//- boolean operations
> &&= ||= !!= //=
> and orxor
Hmmm, given Larry's comments just now about about similar things not
looking similar, I really think | vs ! is a mistake. Fr
On Wed, Oct 30, 2002 at 06:51:14AM +1100, Damian Conway wrote:
> String complement treats the value as a string then bitwise complements every
> bit of each character.
Is that the complement of the codepoint or the individual bytes?
(I'm thinking utf8 here).
--
Nothing ventured, nothing lost.
On Tue, Oct 29, 2002 at 02:55:57PM -0500, Uri Guttman wrote:
>
> damian's syntax table and his use of the term vectorizing made me wonder
> why we call his [op] thing a hyperoperator? the word hyper i assume came
> from hyperdimensional. but calling [] the vectorizing (or just vectored)
> op varia
On Thu, May 12, 2005 at 09:06:48PM +0100, Benjamin Smith wrote:
> sub foo { my $x; BEGIN { $x = 3 }; say $x }
> foo; foo; foo;
>
> Currently in perl5 and pugs this prints "3\n\n\n".
>
> Should BEGIN blocks be able to modify values in lexical variables that
> don't really exist yet? (People ca
1 - 100 of 193 matches
Mail list logo
