On Mon, Jul 31, 2000 at 11:14:34PM -0400, Matthew Persico wrote:
> The original format stuff HAS to be kept. Don't document it so as not to
> encourage its use.
Deliberately leaving things undocumented? I'm sorry, you must have us
confused with another language.
--
Doubt is a pain too lonely to
On Tue, Aug 01, 2000 at 01:13:17PM +0200, Edwin Steiner wrote:
> > Perl isn't a programming language - Perl's grammar is much more like
> > a natural language than a computer one.
>
> Well, $I wonder if anyone except @computers can find it natural to put a
> f... $dollar_sign in front of every $n
On Tue, Aug 01, 2000 at 07:29:05AM -0600, Tom Christiansen wrote:
> I suggest that the language list discuss this very matter: what
> Perl really *is*, so that we know the tenets and principles against
> which proposals can be measured.
Let's do that. Here's my opening gambit:
Well, enough clo
On Tue, Aug 01, 2000 at 08:00:54AM -0600, Tom Christiansen wrote:
> I did the "What is Perl?" thing to focus folks on what this was
> really for, since many seem to be trying to create a new and different
> language now. And you've said all that here just fine.
Bingo. We're redesigning *Perl*. W
On Tue, Aug 01, 2000 at 03:07:36PM -0600, Nathan Torkington wrote:
> I disagree. If there was a bsdm.pm or -B option that gave strong type
> checking, then many would be happy.
You can do this with attributes and tying.
--
Also note that i knew _far_ more about the people that call address
mu
On Tue, Aug 01, 2000 at 05:51:29PM -0600, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more conf
On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
> I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
> better, but I do mind making it optional.
If we're going to do line disciplines, we need a built-in stdio replacement.
Full ground-up rewrite, like sfio bu
On Tue, Aug 01, 2000 at 11:01:14PM -0400, Dan Sugalski wrote:
> Right, I know the underside will be yanked and redone. (Hopefully with
> async support on platforms that have it to do some I/O and processing
> overlap) It's not getting removed from the core language from a perl
> programmer stan
On Wed, Aug 02, 2000 at 02:18:07PM +1000, Damian Conway wrote:
>> 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 good postcondition is either invisible to
On Wed, Aug 02, 2000 at 12:10:38PM +0100, Leon Brocard wrote:
> The AUTOLOAD subroutine should be able to decline a request
Given that I just whinged about this on p5p, YES.
> =head2 $AUTOLOAD
>
> While we're at it, it may be a good idea to remove the global
> $AUTOLOAD variable and instead pas
On Wed, Aug 02, 2000 at 12:22:10PM -0400, John Porter wrote:
> sub interleave(\@;\@\@\@\@\@\@\@\@) {
...
> }
>
> sub mapf(&;\@\@\@\@\@\@\@\@\@) {
...
> }
>
>
> I guess my question is, why do these need to be builtins?
sub push (\@@) { @{$_[0]} = (@{$_[0]}, @_[1..@_]); }
--
Just imagine
On Wed, Aug 02, 2000 at 01:48:36PM -0600, Tom Christiansen wrote:
> >Isn't this covered by locales?
> Unicode and locales are immiscible.
In Perl 5. This is *by no means* a general statement.
ICU is, for instance, a Unicode locale library.
--
Gosh that takes me back... or is it forward? That's
On Wed, Aug 02, 2000 at 04:32:40PM +0100, Andy Wardley wrote:
> This would permit the rationalisation and simplification of the syntax
> required to access individual elements or slices of arrays and hash arrays,
> while remaining backwardly compatible with Perl5 syntax.
This is the rationale? So
On Wed, Aug 02, 2000 at 05:31:06PM -0400, Ted Ashton wrote:
> But that, precisely, was my point: Arrays *and* hashes.
Scalars, hashes, arrays. There's actually more than one type of plural here,
gramatically:
scalars hashes arrays
singulardualplural
(Or am I the only one l
On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote:
> I tend to agree with Tom's argument here. open() is kind of funny
> anyways. Why couldn't it work like this, similar to FileHandle:
>
>$fh = open $filename;
Testing for failure. It's a basic tenet that system calls can be
tested
On Wed, Aug 02, 2000 at 08:05:15PM -0600, Tom Christiansen wrote:
> >I've just asked for a multiline comment sublist to be set up. Do any
> >of the rest of these RFCs want/need a sublist?
>
> What is the purpose of ghettoizing everying cohering topic?
To get those people who actually care a
On Wed, Aug 02, 2000 at 08:13:08PM -0600, Tom Christiansen wrote:
> >> Making us subscribe to infinite lists to wear us down?
> >You know about perl6-all, right?
>
> Which is the very problem of which I was speaking.
> Secret cabals and all.
So secret it was recorded on:
i) The perl6 metalis
On Wed, Aug 02, 2000 at 08:27:19PM -0600, Tom Christiansen wrote:
> Should one really have to find the the time to read each of *hundreds*
> of messages each and every day in order to keep up with this stuff?
Nope. That's why you can select which lists you want to join.
I think you're trying to h
On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote:
> > That Perl should stay Perl
>
> Do we need an RFC for this? Seems like this is more of a "guiding
> concept" that should be intergrated into everything. Just my opinion.
Then we need to enshrine it. I'll cook something up soon.
--
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
> Ah, but we could make the language support this:
>
> localtime->{'day', 'month', 'year'}
>
> in hash-slice fashion.
That's really scary and I like it a lot.
--
"If you want to travel around the world and be invited to speak
On Thu, Aug 03, 2000 at 02:31:01PM +0300, Roman M . Parparov wrote:
> Is any core support for Bidirectional languages going to be implemented?
If I get my way, yes. I will be fighting for this.
--
What happens if a big asteroid hits the Earth? Judging from realistic
simulations involving a sle
On Thu, Aug 03, 2000 at 09:02:12AM -0600, Tom Christiansen wrote:
> >> localtime->{'day', 'month', 'year'}
> >That's really scary and I like it a lot.
> That already has a meaning, thank you very much. :-(
Fair enough. "If it looks like it should be valid Perl, it probably is."
(or similar)
-
On Thu, Aug 03, 2000 at 10:48:17AM -0400, John Porter wrote:
> Not saying we should eliminate all the fun; but keeping something
> on the merit of it's being fun is probably at odds with the goal
> of make Perl more widely acceptable.
Contrary to popular belief, people like having fun.
--
IBM
On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
> Reading through the docs for perl prototypes I see that there is a
> reference to "named parameters" being a possibility in future versions of
> perl.
>
> Does anyone have a more concrete example of what was intended there?
sub mari
On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > Keep default Perl free of constraints such as warnings and strict.
>
> I second this.
I third this. Perl is not, nor do I believe it ever should become, a B&D
language by default. "Making easy things easy", remember that?
--
On Fri, Aug 04, 2000 at 12:36:35AM -0500, J. David Blackstone wrote:
> Perhaps stackable tie-ing and stackable filehandles can both be
> implemented as specific examples of something more general.
Perhaps, but I find it unlikely; stackable filehandles has to happen
at a much lower level. Althou
On Fri, Aug 04, 2000 at 09:05:38AM -0700, Nathan Wiger wrote:
> Suggestion: Can we manually renumber this "RFC 0"? This should be the
> first one at the top of the list, not buried somewhere within. my($.02).
We *shouldn't* need to spell this out for people.
It really, really terrifies me that we
On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote:
> 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.
Which you need at runtime, even in compiled code, to run external
confi
On Fri, Aug 04, 2000 at 02:50:39PM -0400, Chaim Frenkel wrote:
> Its a higher level construct. Akin to telling your interior decorator
> that you'd like the furniture to match the wallpaper. You've left
> out all the details but the decorator can easily see what you're talking
> about.
>
> So ca
On Fri, Aug 04, 2000 at 11:31:30PM -0400, Ken Fox wrote:
> > not because language design is a fun thing to do of an evening.
>
> Huh? You mean I'm supposed to pretend to not enjoy myself? I keep
> all my hair shirts at work, thanks.
Don't be stupid. I said we're *primarily* doing it for the good
On Sat, Aug 05, 2000 at 11:47:47PM +1000, Jeremy Howard wrote:
> I feel that your RFC misses the inclusive nature of perl.
Then I withdraw it. Perl should not stay Perl, fuck it. Call me when it's
time to get coding.
--
Life would be so much easier if we could just look at the source code.
On Sun, Aug 06, 2000 at 12:35:58AM +1000, [EMAIL PROTECTED] wrote:
> I do *not* want to see any more obscenity of name calling here. It does
> nothing to advance the purposes of this working group, and discourages
> people from contributing.
You're quite right, I went too far there. Yes, I was f
On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote:
> Right. That was my point. (The original poster wanted to pull IO out of the
> core entirely)
Ah. Barbarians-at-gates approach, then. On the other hand, there is
a lot of rubbish that *can* go out of core; I'd like to see core being
(Damn these CC's!)
On Fri, Aug 18, 2000 at 09:19:55AM -0700, Larry Wall wrote:
> We seem to be asking for contradictory things here. If it's truly
> opaque, the programmer shouldn't care whether it's polymorphic or
> monomorphic.
That's right.
> I'm inclined to think the polymorphic solution w
On Fri, Sep 15, 2000 at 05:56:36AM -, Perl6 RFC Librarian wrote:
> $foo = 'def';
> $bar = 'ghi';
> $x = "abc$foo$bar";
> $y = 'abc$foo$bar';
>
> There is no way to turn obtain the value of $x from the value of $y.
> In other words, while $foo and $bar were interp
On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
> The current method in which C<__WARN__> and C<__DIE__> signal handlers are
> used is limited in 2ways:
>
> =over 8
>
> =item It does not allow them to accept robust parameter lists.
>
> =item It does not allow for multiple l
On Sat, Sep 16, 2000 at 11:38:57PM -0400, Chaim Frenkel wrote:
> I thought he was asking for evaluating until nothing is left to interpolate.
>
> Something akin to:
> $x = eval "$x" while $x =~ /[$@]/;
> But more intelligent.
OK, fair enough; and I appreciate the point that other double qu
On Mon, Sep 18, 2000 at 10:51:52AM -0400, John Porter wrote:
> Are all the possible attributes going to be predefined, or can the
> user define new ones?
The user should be able to do anything they damn well like. This is,
allegedly, Perl, which means it's about making it easy to do what the
pro
On Mon, Sep 25, 2000 at 06:33:07PM +1100, Jeremy Howard wrote:
> Can we extend RFC 282 so that it allows the right operand of C<..> to be
> omitted in any index, since the upper-bound can be implied? Or does it
> already propose this?
Yes, I wanted this to apply to all slices.
> (...in which cas
On Mon, Sep 25, 2000 at 09:55:38AM +0100, Richard Proctor wrote:
> While this may be a fun thing to do - why? what is the application?
I think I said in the RFC, didn't I? It's extending the counting use of tr///
to allow you to count several different letters at once. For instance, letter
frequ
On Mon, Sep 25, 2000 at 06:07:01AM -0700, Randal L. Schwartz wrote:
> Bart> character it finds. Plus, in Perl 5, NO core function returns a hash.
> Bart> None at all.
>
> It's not returning a hash.
Precisely. There ain't no such thing as "hash context". It simply returns a
list with an even num
On Mon, Sep 25, 2000 at 03:30:47PM +0200, Bart Lateur wrote:
> If you can garantee that it's also not using a hash internally to keep
> count, but instead a table parallel to the table that's being used to
> hold the conversion values, you've won me over.
Naturally, it's hard to guarantee anythin
On Mon, Sep 25, 2000 at 01:55:10PM +0100, Richard Proctor wrote:
> It does not seem to have much to do with tr///, if you want it, why not put it
> in a module with some meaningful name such as histogram()?
Hm. Counting doesn't have much to do with tr///, if you think of it like that.
Now, if y
On Mon, Sep 25, 2000 at 11:10:04AM -0700, Nathan Wiger wrote:
> Indeed. It is also worth noting that people on -flow have been hashing
> out safe signals through a "use signal" pragma, which would remove %SIG
> altogether.
Oh, well, OK. Then this RFC's necessary, dammit! :)
> I like it! But I'm
On Mon, Sep 25, 2000 at 06:37:58PM -, Perl6 RFC Librarian wrote:
> This RFC proposes that the interface to Perl's source filtering facilities
> be made much easier to use.
Hm. I've just sent in the "line disciplines" RFC, which probably will end up
obsoleting a reasonable chunk of this.
--
On Mon, Sep 25, 2000 at 02:49:29PM -0400, Uri Guttman wrote:
> and how do they nest or get localized? with use signal you can install a
> lexically scoped handler or a package level handler. with WARN it looks
> like a global handler to me.
They're special subs. They nest and get localized like s
On Mon, Sep 25, 2000 at 03:10:47PM -0400, Uri Guttman wrote:
> in what order? like BEGIN and END?
Whatever, yes.
> what if you wanted a block scoped warn handler?
What about it? (Or did someone eat the "local" keyword already?)
> i think it would be better to have some explicit way of
> sett
On Tue, Sep 26, 2000 at 02:06:47PM -0400, John Porter wrote:
> > Since when do parentheses make things less readable?
>
> Can you say "lisp"?
"lisp".
(defun Schwartzian (func list)
(mapcar
(lambda (x) (car x))
(sort
(mapcar
(lambda (x) (cons x (funcall func x)))
list
On Tue, Sep 26, 2000 at 12:43:07PM -0700, Robert Mathews wrote:
> Ok, you've proved that lisp doesn't make sense without all those
> annoying parentheses. Congratulations. Fortunately, perl isn't lisp.
Correct, John bringing lisp into the discussion *was* a canard.
--
Writing software is more
On Wed, Sep 27, 2000 at 09:52:57AM +0100, 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 Perl syntax, but it's still clear
> what's going on.
I'd go further
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> The concept of C as opposed to C is sometimes difficult for
> people to understand.
"People" in this context being the people who are reading perl6-language and
purporting to be able to know what Perl 6 needs. People who ought
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.
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you f
On Wed, Sep 27, 2000 at 10:30:36AM -0500, David Grove wrote:
> Although I have no interest in saying anything supportive of this idea, I think
> it would be dreadfully funny if Python suddenly lost its primary point of
> advocacy against the Perl language just because we allowed (not required)
On Wed, Sep 27, 2000 at 02:45:24PM -0400, John Porter wrote:
> But on a tangential note: has anyone proposed letting
> functions, perhaps by prototype, allow the autoquoting
> of arguments?
I thought about it, but it's hard to know when to stop.
use fewer sewers;
would be fine, and I'd lik
On Wed, Sep 27, 2000 at 03:35:39PM -0400, John Porter wrote:
> Yes, but it's hard to read. Lisp requires parens, because it
> has no precedence rules. (Well, hardly any). It has (almost)
> no other syntax. This is the situation we would like to avoid
> in perl. By letting every operator have w
On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote:
> On Wed, 27 Sep 2000, Nathan Wiger wrote:
> > Y'know, I couldn't have said this better myself. :-) I've always felt
> > that "use English" was a waste of time and effort, a bandaid trying to
> > act as a tourniquet.
>
> I think it's
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 @INC directly, Tom,
> instead of use'ing lib?
I call "non
On Fri, Sep 29, 2000 at 02:34:55AM +, Ed Mills wrote:
> I tried to contribute on this list bu
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
On Fri, Sep 29, 2000 at 09:39:20AM +0100, Simon Cozens wrote:
> On Fri, Sep 29, 2000 at 02:34:55AM +, Ed Mills wrote:
> > I tried to contribute on this list bu
[You know, I think something went wrong there. Let's try again.]
The RFC process gets you a hotline to Larry on an
On Fri, Sep 29, 2000 at 04:13:46PM +0100, Piers Cawley wrote:
> Did anyone suggest the following yet?
> package Foo;
> my sub _helper_function { ... }
Todo:
lexically scoped functions: my sub foo { ... }
the basic concept is easy and sound,
the difficulties begin with
On Sat, Sep 30, 2000 at 03:48:07PM +0300, Ariel Scolnicov wrote:
> This is done in Lisp, and other functional languages. Lisp lets you
> declare mutually recursive objects using the (letrec ...) form. In
> Scheme, say:
>
> (letrec ((even? (lambda (x) (if (= x 0) t (odd? (- x 1)
>
On Wed, Oct 04, 2000 at 08:36:32AM -0700, Nathan Wiger wrote:
> against them. The whole point of this Perl 6 process is to develop a
> language that the community thinks is the right direction, right?
Really? I thought the whole point of this was to develop suggestions to
put to Larry, for him to
On Thu, Oct 05, 2000 at 04:53:00PM -0400, John Porter wrote:
> May I point out that "the camel was designed by committee"*, too?
The camel was certainly not, and this Camel isn't going to be either.[1]
> Really, I'd like to see this Designed By Committee Considered Harmful
> myth put to rest.
I
On Fri, Oct 06, 2000 at 11:13:27AM -0400, John Porter wrote:
> Simon Cozens wrote:
> > On Thu, Oct 05, 2000 at 04:53:00PM -0400, John Porter wrote:
> > > May I point out that "the camel was designed by committee"*, too?
> >
> > The camel was certainly not
On Sun, Oct 08, 2000 at 01:12:13PM +0100, raptor wrote:
> [ for in ]
> Can this be done easly at the moment OR via some of the new proposals ?!!!?
map { expression } sequence
--
I used to be disgusted, now I find I'm just amused.
-- Elvis Costello
On Thu, Oct 19, 2000 at 04:47:10PM +0100, raptor wrote:
> What will be the Perl6 code name ?
I vote for "Perl 6".
> even the perl books has some animal to represent the main idea behind...
Well, no, the O'Reilly ones had, but then most O'Reilly books have animals on
them. Oh, and Beginning Perl
On Mon, Oct 23, 2000 at 07:44:15PM +0200, Gerrit Haase wrote:
> Perl, which allows object oriented syntax, written in C++ language,
^^
Did I miss something, or did the world go *totally* gaga overnight?
--
It's all fun and games until som
On Mon, Oct 23, 2000 at 02:39:14PM -0400, Dan Sugalski wrote:
> Got me. I'd planned on us writing perl 6 in INTERCAL.
PLEASE LET'S NOT GO THAT WAY
Incidentally, and just to try and raise the tone a little, are we planning on
compiling Perl 6 programs to native binaries?
--
These days, if
On Mon, Oct 23, 2000 at 02:51:40PM -0400, Dan Sugalski wrote:
> > PLEASE LET'S NOT GO THAT WAY
> A... you're no fun! :)
I am, but nurse says I'm not allowed to write INTERCAL any more.
> That is one of the scenarios. There are some issues with it for a project
> like this--spitting out
On Mon, Oct 23, 2000 at 03:37:02PM -0400, Dan Sugalski wrote:
> Well, maybe we can do it in befunge instead.
+!+!@@!!!
> Oh, without a doubt. I'd actually like to get things building such that the
> four main modules--parser, bytecode compiler, optimizer, and execution
> engine--are in separat
On Mon, Oct 23, 2000 at 04:03:12PM -0400, John Porter wrote:
> But we'll probably *implement* perl in Ada, of course.
Bzzt. Ada *used* to be the language that made the world turn. We believe that
the world-turning program was rewritten in Perl in 1997.
--
Thus spake the master programmer:
On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote:
> The one thing that just occurred to me is that we're going to need to
> support multiple interpreter targets simultaneously. Having the back-end
> emit C source isn't going to get those BEGIN blocks very far. :(
Don't forget that t
On Mon, Oct 23, 2000 at 04:51:24PM -0400, Uri Guttman wrote:
> only perl op calls in machine code
I can't make this make any sense. Could you try again?
--
And it should be the law: If you use the word `paradigm' without knowing
what the dictionary says it means, you go to jail. No exceptions.
On Mon, Oct 23, 2000 at 03:40:26PM -0700, Peter Scott wrote:
> >Don't forget that those BEGIN blocks are *supposed* to be instructions
> >to the compiler.
>
> Er, but a lot of people seem to use them for other things :-)
Then they're going to have a shock. This isn't Perl 5 any more, Toto.
> Wh
On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote:
> basically the emitted machine code for TIL is very simplified C
> routine calls and their argument setup and return. all the routine calls
> are to perl ops with just the minimal stack glue code in between them.
OK, you're re-inventin
On Mon, Oct 23, 2000 at 08:33:23PM -0400, Uri Guttman wrote:
> so the TIL generated code would still to parameter setup, then an
> indirect function call and then result handling. it should still be
> faster than an interpreter and simpler to generate than fully compiled
> code.
Is this actually,
On Tue, Oct 24, 2000 at 03:35:31PM +0100, Ajdin Brandic wrote:
> Uff!
Da.
> Why is there a mailing list for perl6 up and running before the version is
> out?
Someone's gotta *write* it. I hear there's a mailing list for Linux 2.4.
--
I _am_ pragmatic. That which works, works, and theory can g
On Sun, Oct 29, 2000 at 01:36:48PM +, David Grove wrote:
> ana: no, not having, none, anti
> phalis: ...
It's the front part of your helmet which protects your nose.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
On Fri, Jan 12, 2001 at 05:11:56PM -0500, Dan Sugalski wrote:
> Barring anyone else doing it, I should go to YAPC and talk about perl 6's
> guts, at least the bits available at that point. TPC too. ('Course, there's
> the question of getting there, but that's a separate issue)
Well, if you can'
On Wed, Jan 31, 2001 at 12:04:46PM +, Nicholas Clark wrote:
> > It doesn't have to be like that. Functions that are not in the core can
> > still be automatically loaded, but only if your code actually uses them.
> > That could make the perl kernel a lot smaller than it is now, and
> > hopeful
On Wed, Jan 31, 2001 at 05:51:27PM -0500, John Porter wrote:
> > you *don't* need to remember
> > you are programming in perl5 or perl6, and get the same functionality.
>
> But you need to remember it anyway, so remembering it for time() is
> no added burden.
Uhm. NO! Remembering that $x+1 thing
On Wed, Jan 31, 2001 at 11:57:43PM +0100, [EMAIL PROTECTED] wrote:
> > Perhaps some of the more grossly UNIX specific things like getpwnam's
> > extended family and the SysV IPC stuff?
>
> But why? What is it going to buy you?
The fact is, they don't need to be there.
And there isn't really a go
On Thu, Feb 01, 2001 at 09:00:47AM -0500, John Porter wrote:
> > Uhm. NO! Remembering that $x+1 things have changed is an "added burden"
> > over remembering that $x things have changed.
>
> Not as x approaches infinity.
We are not changing an infinite number of things.
> Please knock it off wi
On Thu, Feb 01, 2001 at 11:52:37AM -0500, Dan Sugalski wrote:
> > just a method for doing what we currently do with, say, glob or
> >the heavy unicode things?
>
> None of the above. What I'm looking for is the pieces that turn the use of
> a function into an automagic use of the module containi
On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
> The module loaded can define the routines as either regular
> perl subs or opcode functions (the difference is in calling convention
> mainly) and could be the standard mix of perl or compiled code.
>
> Would someone care to take a
On Thu, Feb 01, 2001 at 11:45:16AM -0500, John Porter wrote:
> For example, take a look at RFC 28 (whose title
> happens to be "Perl should stay Perl"): nothing but ill-
> informed, petulant, absurd whinging about certain classes
> of proposed features that the author, in his humble little
> opin
On Thu, Feb 01, 2001 at 05:10:55PM +, Tim Bunce wrote:
> On Thu, Feb 01, 2001 at 04:02:31PM +, Tim Bunce wrote:
> > of the Foo interface (one SX and one pure-perl, for example).
> s/SX/XS/ of course.
Dammit. And there was I thinking you'd already designed the extension
system for Perl 6!
On Fri, Feb 02, 2001 at 03:07:12PM -0600, Jarkko Hietaniemi wrote:
> > When you come up with a solution to this problem, please send an
> > email to ICANN.
>
> I'm not claiming to have solution: I claim that the com.sun.java.Gorkulator
> isn't one.
Public identifiers.
http://www.docbook.org/tdg/
On Thu, Feb 01, 2001 at 07:12:31PM -0600, David L. Nicol wrote:
> sub subname(proto){
> # in here, the bareword "subname" is a magic
> # alias for the lvalue this routine is getting
> # assigned to, if any.
> }
It always confused me in Pascal
On Mon, Feb 05, 2001 at 10:35:56AM -0500, John Porter wrote:
> Or eliminate $ and @ from the language. :-) or rather :-/.
Well, you can do that now that
foo = bar;
calls the AUTOLOADed lvalue sub foo. The rest of the implementation is
left as an exercise for the reader. :)
--
On our camp
On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote:
> > > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
> > > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION =>
> >2 };
> >
> >Very good idea indeed!!! Append the wishlist to add this module to perl6's
On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote:
> Granted, if this was all done with trusted servers it would be really neat,
> but...
TANSTAATS.
--
I used to be disgusted, now I find I'm just amused.
-- Elvis Costello
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?
--
DESPAIR:
It's Always Darkest Just Before it Gets
On Mon, Feb 12, 2001 at 12:11:19AM -0800, yaphet jones wrote:
[Ruby]
> *no god complex
> *no high priests
I'll tell Matz you said that.
--
hantai mo hantai aru:
The reverse side also has a reverse side.
-- Japanese proverb
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > DESTROY would get called twice, which is VERY BAD.
>
> *blink*
> It is? Why?
> I grant you it isn't the clearest way of programming, but "VERY BAD"?
package NuclearReactor::CoolingRod;
sub new {
Reactor->decrease_core_te
On Thu, Feb 15, 2001 at 09:57:13AM -0500, Kirrily Skud Robert wrote:
> Would anyone like to volunteer to do weekly summaries
Well, don't forget that I *do* have people helping me out with the weekly
summaries. I don't know how people want to play this. Do you want:
* One weekly summary of e
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote:
> > I find a "let's require some extra hoops and red tape" not very-Perl like.
> > Perl is there for the programmer; not the other way around.
>
> Please read ``Larry's talk in Atlanta about Perl 6'', the text is in
> http://dev.perl.org/~a
On Fri, Feb 16, 2001 at 10:26:40AM -0500, John Porter wrote:
> Oh, that's a terrific improvement.
> Basically you want to change (= break) the current precedence
> of the comma operator. Thank you, Mr. Language Designer.
John, settle down. None of us profess to be fantastic language designers,
w
On Fri, Feb 16, 2001 at 03:45:21PM -0500, John Porter wrote:
> But they are inextricably bound by perl's parsing rules.
Perl 5's parsing rules. I don't think Perl 6 *has* a parser just yet.
> You can't keep Perl6 Perl5.
See?
--
What happens if a big asteroid hits the Earth? Judging from real
On Sat, Feb 17, 2001 at 08:02:08AM -0800, yaphet jones wrote:
> the tchrist (christiansen) said it best, when he described perl5:
> >>>...an "expert-friendly" language...
And he was right. Perl is *not* deliberately dumbed down, because, unlike
other languages, we do *not* assume our users are du
1 - 100 of 485 matches
Mail list logo
