Edwin Steiner <[EMAIL PROTECTED]> writes:
> In my opinion Perl lacks (at least partially) some features which
> I consider important for scripting languages:
>
> * elimination of pointers (If I want to spend my time considering how
> many dereference operators to use I'll go for ***C++).
> I'm aw
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "TA" == Ted Ashton <[EMAIL PROTECTED]> writes:
>
> TA> In general, they do what you want, unless you want consistency.
>
> Randal, Tom, et. al.
>
> How locked in to your brain is this lack of consistency? How un-perlish
> would it be to clean
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> Magic words.
>
> Iterators
Doable in perl5 already.
> Reduce (e.g. $x = reduce { sum } @list;
Doable in perl5
> Case/Switch
Why? And Damian's already proved it can be done.
--
Piers
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
> > "TA" == Ted Ashton <[EMAIL PROTECTED]> writes:
> TA> In general, they do what you want, unless you want consistency.
>
> CF> Randal, Tom, et. al.
>
> CF> How locked in to your brain is
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> And how about
>
> continuations, generators and co-routines.
Now those'd be nice if they could be added without slowing down the
rest of perl.
--
Piers
Nathan Torkington <[EMAIL PROTECTED]> writes:
> Alan Burlison writes:
> > > The ability to have strong-typing (I don't trust Junior Engineers to get it
> > > right and I don't have time to check every line of code they write)
> >
> > No. No no no no. This approach is fundamentally wrong.
>
> (
Damian Conway <[EMAIL PROTECTED]> writes:
> Peter Scott <[EMAIL PROTECTED]> (I think -- Piers) writes:
>> Though a good post condition would benefit from some sort of
>> unconditional catch of return, I suppose. Perhaps allowing
>> continue on the outer sub block...
>
> Argh, no! A g
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >Typeglobs != symbol tables.
>
> >You can access individual variable bits in the symbol table now without
> >using typeglobs. I don't see why that would have to change.
>
> NB: $main::{fred} does not autoviv a typeglob when used lvaluably,
> but
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >>>>> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>
> >> How locked in to your brain is this lack of consistency? How un-perlish
> >> would it be to cleanup, crypto-context, or the mean
Steve Simmons <[EMAIL PROTECTED]> writes:
> For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
> well. `mod' is `CORE', `FORMATS', etc, as above. A value of 0 means the
> function is actually gone, 1 means it's disappearing next major release,
> 2 mean next minor, etc. The p
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Tue, Aug 01, 2000 at 08:54:27PM -0400, Bryan C.Warnock wrote:
> > There should be an C pragma that gives new life and meaning to
> > void context constructs. In my case, I want it to print to the default
> > filehandle, (which is also implicit
dLux <[EMAIL PROTECTED]> writes:
> Hello!
>
> I want to make do a nested hash structure, which seems like that:
>
> my $pname = $self->{db}->{product}->offers->{ $product_id} ->
> {name};
>
> This kind of structures can be easily created by TableMap.
>
> Problem: If any of the has
So, I've been reading about the Smalltalk Refactoring Browser
http://st-www.cs.uiuc.edu/users/brant/Refactory/RefactoringBrowser.html
and found myself repeatedly thinking. "Wow, that's cool, I want one of
these for Perl".
Now, it's probably possible to build one of these for perl, though I
have t
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >[EMAIL PROTECTED] wrote:
> >> Perl's similarity to English is one of the things that makes it Fun.
>
> >OTOH, being fun (which I admit it is) is one of the reasons many
> >people don't want to think Perl is a serious language.
>
> So what?
Well s
Damian Conway <[EMAIL PROTECTED]> writes:
>> > Perl's similarity to English is one of the things that makes it Fun.
>>
>> OTOH, being fun (which I admit it is) is one of the reasons many
>> people don't want to think Perl is a serious language.
>>
>> Not saying we should
Damian Conway <[EMAIL PROTECTED]> writes:
>> > It was Damian's, no?
>>
>> I bet he has a paper on it.
>
> http://www.csse.monash.edu.au/~damian/Perl/want.proposal
Ooh, I like that. I'm already frustrated with the current lvalue
setup, this would be a big improvement. Actually, I'd
Graham Barr <[EMAIL PROTECTED]> writes:
> On Wed, Aug 02, 2000 at 06:15:48PM +0200, H.Merijn Brand wrote:
> > If I could, I would VETO!
> >
> > This would break about 90% of my scripts. I use the same name for different
> > type of variables to group them:
>
> Why ? Remember there will (hopeful
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >True, but maybe a lower precedance keword is needed like we did
> >or || and &&. I think someone suggested "then"
>
> > print $string1, $string2, "\n" then return 3 if $cond;
>
> >then again, maybe not.
>
> Why not just piss everybody off?
>
>
"raptor" <[EMAIL PROTECTED]> writes:
> > ...and have some_func know it is being called in an iterator context
> > and be able to create it's own iterator. foldr could then be
> > done as...
>
> I think may have not only list,scalar,iterator context. But some way to
> define CONTEXT itself,
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >But that, precisely, was my point: Arrays *and* hashes. If there is more than
> >one plural whatzitz, then why can't there be more than one singular whatzitz?
> >(and don't say, "because plural *means* more than one" :-). If having a
> >filehandl
Nathan Torkington <[EMAIL PROTECTED]> writes:
> Tom Christiansen writes:
> > What is the purpose of ghettoizing everying cohering topic? Making
> > us subscribe to infinite lists to wear us down?
>
> Yes.
>
> If you really care about the topic, you'll join the list. If you
> don't care, stay
Peter Scott <[EMAIL PROTECTED]> writes:
> Glad to see the tide of sentiment towards making strictness the default
> :-) To feed my personal fetish for optional site policies prohibiting
> disabling certain strictness, can anyone enumerate circumstances when you
> *cannot* currently achieve so
Ken Fox <[EMAIL PROTECTED]> writes:
> Nathan Wiger wrote:
> > Because it has opportunity for bloat, I would suggest it should be in a
> > pragma:
> >
> >use strict 'prototypes';
>
> Bloat? What bloat? I don't want to *bloat* all my programs by sticking
> a zillion pragmas in just to turn on
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Indirect calls might not be a problem, depending on how much flow analysis
> we can do in the optimizer. While that won't be much in the
> on-the-fly-compile version (a 10s runtime with a 50s compile time's not a
> good thing...) I'm hoping the optimiz
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 02:31 PM 8/4/00 +0200, dLux wrote:
> > My suggestion is: declare "eval $scalar" as a bad guy.
>
> It's not just string eval. It's also do FILE and require.
>
> It's a powerful construct, though, and I wouldn't declare it as evil.
> Possibly as "u
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> Maintainer: Simon Cozens <[EMAIL PROTECTED]>
>
> =item Object Orientation
>
> Some things just don't need heavy object orientation. B things
> don't need heavy object orientation, and it's not Perlthink to force
> programmers into onerous r
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 05:31 AM 8/7/00 +1000, Damian Conway wrote:
> >> >Another one for my wish list: deep copying support built in. A devil
> >> >inside me thinks this should be a new assignment
> >> >operator. Damian? Sounds like this is up your alley. I
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> =head1 DESCRIPTION
>
> At present C only returns the index of the first occurrence of a
> specified substring. It is proposed that C take a fourth parameter
> telling it which occurrence of a specified substring to locate:
>
> $first = in
Nathan Wiger <[EMAIL PROTECTED]> writes:
> > > But it isn't "here" that's the problem. If we just wanted to change
> > > the value "here", we could use my(). The problem is that local()
> > > changes the value for somewhere else as well as here.
> >
> > Well, as has been pointed out, special^W
Nathan Torkington <[EMAIL PROTECTED]> writes:
> John Porter writes:
> >> Compilation: Remove requirement for final true value in require'd and
> >> do'ed files
> >
> > Do not. I use this feature.
>
> Is there any reason you couldn't use "die" instead?
Is there any reason that both couldn't be
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Proposal to utilize C<*> as the prefix to magic subroutines
I freely accept that this is not anything approaching a reasoned
critique but:
Yecch!
Peter Scott <[EMAIL PROTECTED]> writes:
> At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
> >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
> >
> > >I meant that BEGIN, END, and INIT aren't declared as subs at present but
> > >named blocks. I was surprised to discover that they're put in th
"Peter Bevan" <[EMAIL PROTECTED]> writes:
> Just a thought, but I think it woul be a good idea to include the
> 'java-esqe' practice of including packages via foo.barr.*
> or in Perl's case Foo::Bar::* (assume that the module include syntax remains
> the same)...
>
> I can see that in the case o
Leon Brocard <[EMAIL PROTECTED]> writes:
> Martyn J. Pearce sent the following bits through the ether:
>
> > I use this in one-liners, and it's _dead_ handy
>
> May I suggest that Perl6 will be a different language? I've seen the
> "I use it, don't change it" argument a couple of times now and
Dan Sugalski <[EMAIL PROTECTED]> writes:
> From a language perspective, I have a scheme to allow us to yank all the
> cruft (sockets, shm, messages, localtime...) out into separate libraries,
> yet pull them in on demand without needing a use.
a la dbmopen in perl5?
--
Piers
Peter Scott <[EMAIL PROTECTED]> writes:
> At 09:28 AM 8/8/00 +0100, Piers Cawley wrote:
> >Peter Scott <[EMAIL PROTECTED]> writes:
> >
> > > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
> > > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrot
Uri Guttman <[EMAIL PROTECTED]> writes:
> some people have mentioned help strings as special parts of a sub
> declaration like gnu lisp has. this could be more support for that type
> of thing. but i don't want it to be too strange.
Hmm...
sub foo ($$;@) :lvalue
"Documentation string h
Peter Scott <[EMAIL PROTECTED]> writes:
> >=head1 TITLE
> >
> >Higher order functions
>
> Well, this should keep the Obfuscated Perl Contest going for at least
> another decade :-)
Whilst still being deeply useful in non obfuscatory contexts too.
--
Piers
John Porter <[EMAIL PROTECTED]> writes:
> Michael Fowler wrote:
> >
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
>
> I personally would like to have the stringification of refs be a
> symmetric operation, i.e. such
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> One thing that isn't addressed in any of the exception RFC's (and it
> may not be appropriate) is how to actually use it. Not in the syntactical
> or semantic meaning. But in how to use it practically.
>
> Given six lines of code within a trapping cont
Graham Barr <[EMAIL PROTECTED]> writes:
> Damian Conway <[EMAIL PROTECTED]> writes:
> >Leon Brocard writes:
> >> =head2 $AUTOLOAD
> >>
> >> While we're at it, it *may* be a good idea to remove the
> >> global $AUTOLOAD variable and instead pass it as the first
> >> paramet
Damian Conway <[EMAIL PROTECTED]> writes:
>> Are the two values of a pair restricted in anyway? All your examples
>> were scalar.
>
> Yes. The two components must be scalars.
> The key is stringified iff it's a bareword.
> Otherwise no restrictions.
So assuming pairs are scalars...
Graham Barr <[EMAIL PROTECTED]> writes:
> On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote:
> > Mike-
> >
> > Jeremy's got a great explanation of this, which I'll paraphrase, but the
> > discussion went through lots of iterations. Think of the ^ as a carat or
> > thumbtack, holding t
Graham Barr <[EMAIL PROTECTED]> writes:
> On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
> > > /^_/
> > >
> > > What is that matching ?
> >
> > We've done this. It's matching a string that begins with '_'. W
John Porter <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> >
> > The (continue|always|finally|whatever) clause will *always* be
> > executed, even if one of the catch clauses does a die, so you can use
> > this to roll back the database transaction or w
John Porter <[EMAIL PROTECTED]> writes:
> > Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
> > multidimensionals.
>
> Combined with highlander variables, and there ceases to be a problem.
Will you stop with the highlander variables?
--
Piers
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >>>>> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>
> PC> The (continue|always|finally|whatever) clause will *always* be
> PC> executed, even if one of the catch clauses does a die, so you c
Nathan Wiger <[EMAIL PROTECTED]> writes:
> Jarkko Hietaniemi wrote:
> >
> > The $a and $b of the sort comparator were A Bad Idea to begin with.
>
> Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't
> be used, or even a more standard $1 and $2. Either one makes it more
> ob
Nathan Wiger <[EMAIL PROTECTED]> writes:
> Nathan Torkington wrote:
> > Not every subroutine corresponds to a method call exposing
> > object-internal data. Most of my subroutines *do* something and make
> > no sense to be called lvaluably. Explicit marking the compiler pick
> > up assignments t
"J. David Blackstone" <[EMAIL PROTECTED]> writes:
> I find the standard prefix symbols so intuitive I find it hard to
> articulate the reasons why I balk at giving them up. It's like
> explaining breathing or the ability to distinguish colors.
Bravo! What he said! Hear, hear!
[FX: Waves order
[EMAIL PROTECTED] writes:
> Please take this discussion to the new -errors sublist. Thanks in
> advance!
Exceptions are not necessarily errors. This belongs in
perl-language-flow surely?
--
Piers
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Wed, Aug 16, 2000 at 10:59:38AM +0100, Piers Cawley wrote:
> > Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> > > This RFC proposes that lvalue subs, when invoked as such, should receive
> > > the rva
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This RFC proposes that lvalue subs, when invoked as such, should receive
> the rvalue being assigned to it as an argument.
I'm kind of in two minds about this. Most of the time the current
lvalue behaviour does pretty much the Right Thing, and sim
Damian Conway <[EMAIL PROTECTED]> writes:
> I'd like to say that I whole-heartedly endorse the sentiments expressed in
> this RFC (and *not* just because it likes my book! ;-)
Well, it is a very good book...
> Well done, John.
Seconded.
--
Piers
Larry Wall <[EMAIL PROTECTED]> writes:
> If you're into dwimmery, you could make all of these work, too:
>
> print (1, 2, 4, ...)
> print (1, 4, 9, 16, 25, ...)
> print (1, 1, 2, 3, 5, ...)
> print ('a', 'b', 'c', ...)
> print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
You forgot:
Nathan Wigner, disguised as Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
[...]
Gut feeling, I don't like this proposal. Examples coming up.
> Increases in namespace are basically always beneficial.
>
> =head2 Potential Problems
>
> This approach is not without its problems. These need to b
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >Object-oriented features were added to Perl with version 5, and in many
> >ways still appear somewhat "tacked on", with perhaps undue respect
> >for the Old Ways of Perl 4.
>
> [NB: This is not a serious missive.]
>
> Hey, that Perl uses package
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> =head1 DESCRIPTION
>
> One of the most common mistakes I make is forgetting a C<;> after
> C, probably because I'm thinking ``if'' and an if doesn't
> require a C<:> after it's closing C<}>. I'll type, for example,
>
> $cond and do {
>
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
>
> >=head1 TITLE
>
> >Eliminate bareword filehandles.
>
> "Eliminate" is such a strong word. You're saying that we can't
> use STDIN, STDOUT, STDERR, ARGV, or DATA an
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >I intend to extend the parameter lists RFC to cover optional
> >(non-tailing) arguments.
>
> Will this include having typed variadic functions, allowing you, for
> example, to say something like
>
> This function takes any number of arrays, a
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >Doesn't that tend to lead us in the direction of pack madness where we
> >end up with yet another 'sub language' within perl. We've already got
> >pack specifiers and regexen and the 'old' prototyping stuff. I'm not
> >arguing *against* these things
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >IMHO Perl should add a plethora of higher-order functions for arrays and
> >hashes, and from the chatter here I think a lot of people agree.
>
> Make some modules, release them, and see how much they're used. Then
> one can contemplate sucking
Piers Cawley <[EMAIL PROTECTED]> writes:
> Damian Conway <[EMAIL PROTECTED]> writes:
>
> >> Are the two values of a pair restricted in anyway? All your examples
> >> were scalar.
> >
> > Yes. The two components must be scalars
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >I don't want a set representation. I want set operations. And somehow
> >for this having to add a use statment and who knows what overhead for
> >what seems to be a simple operation is a pain.
>
> The overhead is not that it should be a module, but
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects: C pragma
>
> =head1 VERSION
>
> Maintainer: Damian Conway <[EMAIL PROTECTED]>
> Date: 14 September 2000
> Mailing List: [EMAIL PRO
Nathan Wiger <[EMAIL PROTECTED]> writes:
> It seems potentially useful to be able to say:
>
>my Dog, Cat $fluffy;
>
> As a way to say "$fluffy can be either a Dog or a Cat". Since variables
> are prefixed, anything comma-separated up to the variable is an
> alternate class for that variable:
Robert Mathews <[EMAIL PROTECTED]> writes:
> Simon Cozens wrote:
> > (defun Schwartzian (func list)
> > (mapcar
> >(lambda (x) (car x))
> >(sort
> > (mapcar
> > (lambda (x) (cons x (funcall func x)))
> > list
> > )
> > (lambda (x y) (< (cdr x) (cdr y)))
> > )
Simon Cozens <[EMAIL PROTECTED]> writes:
> Readability is a programmer feature, not a language feature.
The most important optimization a programmer can make is to optimize
for understanding.
--
Piers
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote:
> > Don't change "use less" to "use optimize". We don't
> > need to ruin the cuteness.
>
> "use less 'rolled_loops';" sounds really weird.
We obviously need to introduce a synonymous
C
John Porter <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> >
> > You know, I'm trying to see what's annoying about all those
> > parentheses in the lisp function and what do you know, I can't see
> > anything wrong. Okay, so it's not
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >I strongly agree with the opinion that we should try and get away from
> >special variables and switches in favor of functions and pragmas.
> >Witness 'use base' instead of '@ISA', 'use warnings', and so on.
>
> Huh? Why??? Perl's use of @ISA is
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Thu, Sep 28, 2000 at 02:40:04PM -0400, John Porter wrote:
> > Tom Christiansen wrote:
> > > Perl's use of @ISA is beautiful.
> > >
> > > use base is, or can be, pretty silly --
> > > think pseudohashes, just for one.
> >
> > I suppose you diddle @
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> C
>
[ ... ]
> =head1 ABSTRACT
>
> A pragma to modify the syntax of Perl 6 at run time. Oh yes.
>
[...]
> =head1 IMPLEMENTATION
>
> First, i
Did anyone suggest the following yet?
package Foo;
my sub _helper_function { ... }
sub public_function {
...
helper_function(...);
...
}
# Some other file:
use Foo;
Foo::public_function(@args); # Okay
Foo::_helper_function(@args); # Th
Alan Gutierrez <[EMAIL PROTECTED]> writes:
> On 27 Sep 2000, Piers Cawley wrote:
>
> > Simon Cozens <[EMAIL PROTECTED]> writes:
> >
> > > On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote:
> > > > Don't change "us
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> caller->eval BLOCK
>
> =head1 VERSION
>
> Maintainer: David Nicol <[EMAIL PROTECTED]>
> Date: 28 Sep 2000
> Mailing List: [EMAIL PROTECTED]
"Ed Mills" <[EMAIL PROTECTED]> writes:
> I tried to contribute on this list but it seems we've coalesced downto Tom
> and a handful of others. No one else has a voice.
Hmm... not my experience. But then I've only seen your message here
because of Simon's response to it, my spamfilter sees your
Piers Cawley <[EMAIL PROTECTED]> writes:
> "Ed Mills" <[EMAIL PROTECTED]> writes:
>
> > I tried to contribute on this list but it seems we've coalesced downto Tom
> > and a handful of others. No one else has a voice.
>
> Hmm... not my ex
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Common attribute system to allow user-defined, extensible attributes
>
> =head1 VERSION
>
> Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
> Da
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Perl should not abort when a required file yields a false value
We had this RFC from Damian already didn't we?
--
Piers
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Elements of @_ should be read-only by default
>
> =head1 VERSION
>
> Maintainer: John Tobey <[EMAIL PROTECTED]>
> Date: 28 Sep 2000
> Last
Ariel Scolnicov <[EMAIL PROTECTED]> writes:
[ A bunch of stuff ]
Er, chaps, not wishing to tread on Skud's moderatorial toes and all,
but shouldn't all this be in perl6-internals?
Reply-To: set.
--
Piers
>"David L. Nicol" <[EMAIL PROTECTED]> writes:
>> Piers Cawley <[EMAIL PROTECTED]> writes:
>>> [EMAIL PROTECTED] (Yitzchak Scott-Thoennes) writes:
>>>
>>> > $srt =~ tr/0-9a-z\xe9/a-jA-ZE/; # uc & sort nums after letters
&g
"David L. Nicol" <[EMAIL PROTECTED]> writes:
> Marc Lehmann wrote:
> >
> > On Sat, Dec 30, 2000 at 05:31:29AM +, "David L. Nicol" <[EMAIL PROTECTED]>
>wrote:
> > > I do not know exactly what the perl5 default sort heuristic is,
> > > aside that it tries to DWIM both numeric and string data.
Piers Cawley <[EMAIL PROTECTED]> writes:
> "David L. Nicol" <[EMAIL PROTECTED]> writes:
> > Marc Lehmann wrote:
> > >
> > > On Sat, Dec 30, 2000 at 05:31:29AM +, "David L. Nicol"
><[EMAIL PROTECTED]> wrote:
&g
David Cantrell <[EMAIL PROTECTED]> writes:
> On Thu, Jan 04, 2001 at 09:28:26AM +0000, Piers Cawley wrote:
>
> > And for 'proper' library type sorting (assuming all works are in
> > English) we should really be doing something like:
> >
> >
Did we do this one already?
I have an embarrassingly large amount of code that has to do Cisa('Foo') }>, or Ccan('Bar') }> because there is a
chance that C<$foo> is an unblessed reference.
I would use UNIVERSAL::can directly, but I have some code (a
container/decorator class) that messes with is
Glenn Linderman <[EMAIL PROTECTED]> writes:
> David Cantrell wrote:
>
> > And in any case, I can think of three different ways of saying 1821 in
> > English alone.
> >
> > One thousand eight hundred and twenty one
> > One thousand eight hundred twenty one
> > Eighteen hundred and twenty one
> >
>
[EMAIL PROTECTED] (Andreas J. Koenig) writes:
> > On Fri, 26 Jan 2001 16:37:23 -0500, Michael G Schwern <[EMAIL PROTECTED]> said:
>
> > from what I remember we discussed
> > an idea to allow people and organizations to produce their own list of
> > approved modules.
>
> This is already p
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
> > > Larry mumbled something like "implements" and "interface". So to say
> > >
> > > package Net::FTP::Foo implements Net::FTP;
> > >
> > > But I don't think, anybody wrote an RFC about the plan.
> >
> > I did. Or something like it. And I've
"Branden" <[EMAIL PROTECTED]> writes:
> Of course, C++ has no GC, which is a good thing, but you can always
> fake it with Refcounts, which is much more efficient, and easily
> feasable with C++.
Err... current research shows that the refcount approach is one of the
slowest forms of GC, and it d
"Branden" <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> >"Branden" <[EMAIL PROTECTED]> writes:
> >> Of course, C++ has no GC, which is a good thing, but you can always
> >> fake it with Refcounts, which is much more efficien
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Fri, Feb 09, 2001 at 04:14:34PM -0800, Mark Koopman wrote:
> > > sub test {
> > > my($foo, $bar, %baz);
> > > ...
> > > return \%baz;
> > > }
> > are we considering to deprecate this type of bad style
>
> What bad style?
Well,
Mark Koopman <[EMAIL PROTECTED]> writes:
> > On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
> >
> >
> > That may work for C, but not for Perl.
> >
> > sub test {
> > my($foo, $bar, %baz);
> > ...
> > return \%baz;
> > }
> >
> > You may notice that only PART
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >
> > > Perl needs some level of tracking for objects with finalization attached to
> > > them. Full refcounting isn't required, however.
> >
> >I think I've hea
Peter Scott <[EMAIL PROTECTED]> writes:
> At 09:01 PM 2/15/01 +0100, [EMAIL PROTECTED] wrote:
> >On Thu, Feb 15, 2001 at 11:08:47AM -0800, Edward Peschko wrote:
> > > However, that still doesn't get rid of the gotchas - personally I think that:
>
> > >
> > > my $a, $b, $c;
> > >
> > > should be
Dan Sugalski <[EMAIL PROTECTED]> writes:
> True enough. This is a small subset of general optimizations. For example,
> this:
>
>
>$i = 0;
>foreach (1..1000) {
> $i++;
>}
>
> can be easily optimized to:
>
>$i = 1000;
>
> and most language implementations with any sort of o
[EMAIL PROTECTED] writes:
> English, by comparison shows the effects of protracted foreign
> occupation of English speaking peoples by conquerors who spoke a
> foreign language.
And also of protacted occupation of foreign countries by English
speaking conquerors. Witness the number of Indian loa
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
> On Wed, Apr 04, 2001 at 11:46:12PM -0700, Nathan Torkington wrote:
> > Not a comment at all on it? Was I accidentally unsubscribed to
> > perl6-language?
> >
> > *tap* *tap* is this thing on?
> >
> > Nat
>
> Me, I've been racking my brain to fig
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Thu, Apr 05, 2001 at 01:33:22PM -0700, Edward Peschko wrote:
> > > I'd really rather not, and I don't think that was Larry's intention. I
> > > think rather it was "perl 5 warning/strict levels", not "parse as perl 5
> > > code". At least I hope tha
1 - 100 of 534 matches
Mail list logo
