Re: formats and localtime
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 know that faith is his twin brother. - Kahlil Gibran
Re: perl6 requirements
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 $noun you use. Grammar != vocabulary. -- The Messiah will come. There will be a resurrection of the dead -- all the things that Jews believed in before they got so damn sophisticated. - Rabbi Meir Kahane
What's Perl?
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 clowning around. Perl is, in intent, a cleaned up and summarized version of that wonderful semi-natural language known as "Unix". -- Larry Wall in <[EMAIL PROTECTED]> -- "You can have my Unix system when you pry it from my cold, dead fingers."
Re: perl 6 requirements
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*. We're not *designing* something else. -- "A mind is a terrible thing to have leaking out your ears." -- The League of Sadistic Telepaths
Re: What is Perl?
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 mungers names like 'lusers', 'egoists' or try to make luser giraffes. -- Megahal (trained on asr), 1998-11-06
Re: date interface (was Re: perl6 requirements, on bootstrap)
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 confused and less at home with Perl? I think there's a distinction here between the Unix-and-C mentality (which is good) and the Unix-and-C syntax. (which is not always) C is, at times, less than logical. Witness the localtime fun: some of it's zero-based, some of it's one-based, and some of it's -1900-based. All from the same function. The localtime concept is needed, the localtime brain damage is really not. -- "Little else matters than to write good code." -- Karl Lehenbauer
Re: date interface (was Re: perl6 requirements, on bootstrap)
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 but Perlish. -- [Bastille Linux] Of course, if we consider the relative ease with which the historical Bastille was taken by a bunch of peasants, maybe there's not much difference between the two. - Jonathan Byrne.
Re: date interface (was Re: perl6 requirements, on bootstrap)
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 standpoint, though. Beefed up with disciplines and stuff, rather > than removed. Egads no. IO's what Perl's for. -- Calm down, it's *only* ones and zeroes.
Re: type-checking [Was: What is Perl?]
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 the client code, or > makes its presence felt only through the effect of turning a bad final > state (or return value) into an exception. It does *not* offer a last > chance to monkey with the return value! http://bumppo.net/lists/fun-with-perl/2000/08/msg0.html -- Life would be so much easier if we could just look at the source code. -- Dave Olson
Re: RFC: AUTOLOAD declining
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 pass it as the first parameter of the
> AUTOLOAD subroutine call.
Why, other than generic global drought? I'd prefer not to have to
fiddle with the args when despatching a subroutine call. Contrast:
sub AUTOLOAD {
my $sub = shift;
# Make sub exist;
goto &$sub;
}
and
sub AUTOLOAD {
# Make sub exist
goto &$AUTOLOAD;
}
Also, you're breaking the "subroutine parameters end up as @_" paradigm,
and AUTOLOAD suddenly because more "special" than it currently is. In
fact, it starts to look like a method call. And what if you have autoloaded
methods:
sub AUTOLOAD {
my ($sub, $object) = (shift, shift);
...
}
Blegh.
--
"So i get the chance to reread my postings to asr at times, with a
corresponding conservation of the almighty leviam00se, Kai Henningsen."
-- Megahal (trained on asr), 1998-11-06
Re: Reduce [was: Re: Random items (old p5p issues)]
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 we are meeting the aliens for the first time.
Most people would just shoot them to see how many points they are
worth.
Re: Removing/fixing $[line noise here] variables
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 the trouble with time travel, you never can tell." -- Doctor Who, "Androids of Tara"
Re: RFC: Highlander Variables
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? Sounds a bit of assault on Perl's flexibility for this little gain. As Randal said, there's no teaching advantage in it. -- "The Amiga is the only personal computer where you can run a multitasking operating system and get realtime performance, out of the box." -- Peter da Silva
Re: RFC: Filehandle type-defining punctuation
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 left who did Ancient Greek? :) > (and don't say, "because plural *means* more than one" :-). If having a > filehandle character would make the code clearer, then let's do it. If it would, yes. I'm not convinced that it would. But I do concede that people see filehandles as something conceptually different from an "ordinary" scalar. -- On our campus the UNIX system has proved to be not only an effective software tool, but an agent of technical and social change within the University. - John Lions (U. of NSW)
Re: RFC: Filehandle type-defining punctuation
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 for success and failure by their returned truth values. I believe we should keep this. system() is the warty exception. -- A bug in the code is worth two in the documentation.
Re: RFC stuff
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 about multi-line comments away from those who really don't give a damn. > Making us subscribe to infinite lists to wear us down? You know about perl6-all, right? -- I respect faith, but doubt is what gives you an education. -- Wilson Mizner
Re: RFC stuff
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 metalist, as linked from the Perl 6 home page ii) perl6-announce iii) use.perl.org iv) bootstrap v) www.news.perl.org ... -- "Which you then convert to gold, non-perishable food, firearms, good liquor & a secluded hideaway in the last of the internet official protocol standards" -- Megahal (trained on asr), 1998-11-05
Re: RFC stuff
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 have it both ways. If you don't want to hear about a certain thing, don't join the list about it. If you want to have everything, join perl6-all. > Is there an open NNTP server running with all these as the perl.* > groups? That would help a lot. It would, yes. I've been toying with the idea of setting one up, but I think it should be news.perl.org Ask, are you busy enough yet? :) -- God gave man two ears and one tongue so that we listen twice as much as we speak. -- Arab proverb
Re: RFC stuff
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. -- Apr 13 11:05:20 apollo13 fsck[3927]: root, we have a problem. - Jeff Gostin <[EMAIL PROTECTED]>
Re: date interface (was Re: perl6 requirements, on bootstrap)
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 at a lot
of different places, just write a Unix operating system."
(By Linus Torvalds)
Re: BiDirectional Support in Perl6
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 sledge hammer and a common laboratory frog, we can assume it will be pretty bad. - Dave Barry
Re: date interface (was Re: perl6 requirements, on bootstrap)
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)
--
IBM Pollyanna Principle:
Machines should work. People should think.
Re: RFC: lexical variables made default
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 Pollyanna Principle: Machines should work. People should think.
Re: named parameters
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 marine ($sailor, $captain) {
$captain->say("One ping only");
}
--
Pray to God, but keep rowing to shore.
-- Russian Proverb
Re: RFC 16 (v1) Keep default Perl free of constraints su
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? -- Wouldn't it be wonderful if real life supported control-Z?
Re: Stackable ties
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. Although a stackable vtable approach to both ties and filehandles may kinda make sense. Or I may be grabbing words out of the air and putting them together in random patterns. -- "Everything's working, try again in half an hour."-chorus.net tech support
Re: RFC 28 (v1) Perl should stay Perl.
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 do. -- If God had a beard, he'd be a UNIX programmer.
Re: Life without eval
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 configuration files written in Perl. Oops! -- Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a garage makes a person a car.
Re: RFC 28 (v1) Perl should stay Perl.
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 calling, adding a little bit of Prolog, is hard to call anti-perl. Right. You don't seem to be getting it, so I'm going to have to be harsh here. You see, there's a way we can canonically verify whether these suggestions have any merit whatsoever, or whether they should be shot down in flames and burnt. Perl, being the practical language that it is, and since we can easily implement reduce and friends in Perl, we can very easily tell if there's a real need for these features by looking at whether anyone has attempted to implement them. So, if you can point me at a CPAN module that does this, I'll concede that *one* person actually cares enough about these things to do something about it. Of course, one person caring doesn't mean that the need is strong enough for something to go in Perl. There are all sorts of wacky modules out there, not all of which should go in core. If you'd suggested adding support for URI encoding and decoding, I would have laughed a lot less, since that's a feature that a lot of people need, want and use. But what is being proposed is completely and utterly unwanted by the vast majority of Perl users out there. It's pie-in-the-sky ludicrosity from some ivory tower. It may be your hobby-horse, but there *is* no CPAN module to attempt to implement these things, there are no users, nobody wants it, nobody needs it and nobody cares. End of story. So can we please leave these ridiculous delusions behind and get on with some real work? -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
Re: RFC 28 (v1) Perl should stay Perl.
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 of Perl. Well, *I*'m doing it for the good of Perl. > With that said, I could agree with RFC 28 if the insulting and anti- > community rhetoric about computer science and new-ideas-are-bad was > toned down. New ideas are good. Bad ideas are bad. I'm trying to encourage people to draw a distinction, but it doesn't seem to be working. I really don't want to have to be forced to withdraw this RFC, but that's the way it's headed. > (Remember Larry's slide with the Perl influences on it? > Linguistics, Art, Common Sense *and* Computer Science.) I know. My point was that we shouldn't forget the first three in blind pursuit of the forth. -- There are two kinds of egotists: 1) Those who admit it 2) The rest of us
Re: RFC 28 (v1) Perl should stay Perl.
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. -- Dave Olson
Re: RFC 28 (v1) Perl should stay Perl.
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 frustrated but that doesn't excuse bad language and behaviour. My apologies to all on the list. -- "So i get the chance to reread my postings to asr at times, with a corresponding conservation of the almighty leviam00se, Kai Henningsen." -- Megahal (trained on asr), 1998-11-06
Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
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 syntax-plus-essentials. System V IPC, for instance, isn't essential. I think "essential" could be easily defined as "stuff which is portable pretty much everywhere"; the socket stuff can go into a separate library, for instance. This probably wouldn't affect speed too drastically because these things could always be linked in statically a la Dynaloader. But this is now an internals issue, so the list football starts again. Don't you just love arbitrary distinctions? -- VMS must die!
Re: RFC 131 (v1) Internal String Storage to be Opaque
(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 will be > more efficient. Ah. I'm inclined to think the exact opposite, but then I'm more likely to be incorrect. Why do you think what you think? I still don't see the contradiction, incidentally. -- Asynchronous inputs are at the root of our race problems. -- D. Winker and F. Prosser
Re: RFC 229 (v1) Variable interpolation on demand.
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 interpolated into $x, they
> were not interpolated into $y. It would be nice to get Success! from:
>
> $z = interpolate ( $y );
> print 'Success!" if $z eq $x;
sub interpolate {eval "\"@_\""}
Never say "there is no way". There's *always* a way, and 99% of the time it
doesn't need to go in core.
--
"Even if you're on the right track, you'll get run over if you just sit there."
-- Will Rogers
Re: RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
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 layers of handlers. > > =back Random thought[1]: Do these things still need to be signal handlers? Why can't they be ordinary subs? It seems crazy to talk about signal handlers if we may be building Perl on platforms which don't have signals... I suggest "sub WARN" and "sub DIE", although not strongly enough to be bothered to write an RFC for it. Simon [1] I'm not on -language, but I get these random thoughts as I see the RFCs float past on announce; apologies if this has been brought up before. -- SM is fun. ADSM is not. "Safe, Sane, Consensual"... three words that cannot used to describe ADSM. - Graham Reed, sdm.
Re: RFC 229 (v1) Variable interpolation on demand.
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 quotes can get in the way. Even so, this is something which can very easily be done in Perl-space. I realise it's a very unpopular point of view in these parts, but I feel the only things that should go in the core are things that need to be there. Still, carry on churning out those RFCs, eh? -- If God had a beard, he'd be a UNIX programmer.
Re: Accessing a variable's attributes (was Re: RFC 241 (v1) ...)
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 programmer wants to do. > I would think that if it could be done at all, > it would only be in extension (formerly XS) code. Why? I don't want to go to C just to add a flag to a variable. That smacks of making easy things hard and hard things impossible. You'll note that that isn't the motto of Perl. (The deadline for collecting ideas passed two weeks ago. Why is this all still going on?) Simon -- I cannot and will not cut my conscience to fit this year's fashions. -- Lillian Hellman
Re: RFC 282 (v1) Open-ended slices
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 case please give an example of an > open-ended slice on an array rather than directly on a function returning a > list.) Well, there's "C<@array[$foo...]>" in the abstract; does that count? In any case, I think my meaning is sufficiently clear. -- `After all, we're not all freaky perverts' - Thorfinn
Re: RFC 283 (v1) C in array context should return a histogram
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 frequencies in text is an important metric for linguists, codebreakers and others; think about how you'd get letter frequency from a string: $as = $string =~ tr/a//; $bs = $string =~ tr/b//; $cs = $string =~ tr/c//; ... $zs = $string =~ tr/z//; Ugh. (%alphabet) = $string =~ tr/a-z//; Yum. And it's on the Perl 5 wishlist, so it ain't just me that thinks its a worthy idea. -- Putting heated bricks close to the news.admin.net-abuse.* groups. -- Megahal (trained on asr), 1998-11-06
Re: RFC 283 (v1) C in array context should return a histog ram
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 number of elements. Now, when you put that into a hash, the Right Thing happens. And it isn't *that* slow; it uses a table, just like the ordinary way tr/a/b/ operates. That doesn't use a hash! Besides, you pay for what you get: if you want to use this, it'll do all the work for you at *perhaps* a slight speed expense. But it's sure faster than doing n different counts and assigns... -- "Contrariwise," continued Tweedledee, "if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic!" -- Lewis Carroll, "Through the Looking Glass"
Re: RFC 283 (v1) C in array context should return a histog ram
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 anything since this isn't implemented yet, tr/// hasn't happened yet, and not a single line of Perl 6 code has been written. It's a SMOP; "use an array instead of a hash". This changes nothing about the design. It seems I was wrong - when I did implement this before, I did use a hash: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-02/msg01192.html but a parallel table could have been possible and very easy. Incidentally, so what if a hash is slow? You pay for what you get. It's still quicker than doing it by hand. -- "I will make no bargains with terrorist hardware." -- Peter da Silva
Re: RFC 283 (v1) C in array context should return a histogram
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 you wish to raise an RFC which removes the ability to use tr/// to count characters and puts it in a module with some meaningful name such as count(), please be my guest, so that I can laugh heartily. I'm merely extending what's already there. > How did something like this get in the wish list? By dint of being a brilliant idea! (Hah, it was probably only Larry or someone irrelevant like that who put it there... :) -- Anyone who takes words on the screen personally should not be on IRC.
Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs
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 not so sure these are like BEGIN and END - which are > really non-sub blocks - as much as DESTROY, perhaps. But that's a very > subtle nitpick. Blast. Yeah, well. People know what I mean. -- "You can have my Unix system when you pry it from my cold, dead fingers."
Re: RFC 264 (v2) Provide a standard module to simplify the creation of source filters
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. -- The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs
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 subs. -- Pokemon seems an evil concept. Kid hunts animals, and takes them from the wild into captivity, where he trains them to fight, and then fights them to the death against other people's pokemon. Doesn't this remind you of say, cock fighting?
Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs
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 > setting the handlers at runtime (better than %SIG) to give more > control. Are you talking about signals or warn/die now? > maybe instead of use signal, an extension to use warnings. you > can pass it a code ref and/or a list of warnings to enable. Could do that, yeah. -- It's difficult to see the picture when you are inside the frame.
Re: perl6storm #0050
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 ) (lambda (x y) (< (cdr x) (cdr y))) ) ) ) Maybe you'd prefer this: 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 I know which I'd rather read. -- God gave man two ears and one tongue so that we listen twice as much as we speak. -- Arab proverb
Re: perl6storm #0050
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 fun than working.
Re: perl6storm #0050
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 than that. It's clear what's going on for a number of reasons. Firstly, you know the language. Secondly, you know what it's trying to do because the function and the variables are well named. Thirdly, I used whitespace and indentation to make the various levels apparent - that's why I removed the whitespace on the second example. There are many other tricks for making code readable, and whether or not the language supports bracketing or, indeed, any other feature is more or less irrelevant to all of them. You can write clear code in any language, if you take the time; you can write Python in any language, if you want. Readability is a programmer feature, not a language feature. -- "There is no statute of limitations on stupidity." -- Randomly produced by a computer program called Markov3.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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 to really understand Perl and how it works. If this concept is too difficult for them, then it really shouldn't exist. KISS. -- If the code and the comments disagree, then both are probably wrong. -- Norm Schryer
Re: RFC 303 (v1) Keep C, but make it work.
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 from doing clever things. -- Doug Gwyn
Re: perl6storm #0050
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) > blocks by indentation. Maybe then they'd stop invading perl5-advocacy. ;-)) I have a feeling you're *really* going to like one of the RFCs I've just submitted... -- Be not anxious about what you have, but about what you are. -- Pope St. Gregory I
Re: RFC 303 (v1) Keep C, but make it work.
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 like to see it work, but what I *really* wanted was l((apply &foo (mapcar &bar (@wibble -- In related wibbling, I can see an opening for the four lusers of the Apocalypse... "I didn't change anything", "My e-mail doesn't work", "I can't print" and "Is the network broken?". - Paul Mc Auley
Re: perl6storm #0050
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 well-defined precedence, > and every be function well prototyped, there should never be any > ambiguity (to the compiler, at least) as to what is meant, even > with no parens. Ideally, anyway. Perl is English-like. And sometimes in English parentheses *are* necessary to increase both meaning and readability, as your own message proves. -- The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism. - Paul Tomblin, in the monastery.
Re: Expunge "use English" from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
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 a nice little bit of optional sugar and I don't see any reason > to throw it away. The key point is that it's optional. If you think it's a waste of time and effort, don't use it. If other people use it, well... does Perl stop people programming in ways you don't like? -- It is better to wear chains than to believe you are free, and weight yourself down with invisible chains.
Re: Murdering @ISA considered cruel and unusual
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 sequitur"! -- People in a Position to Know, Inc.
Re: Cya dudes
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."
Re: Cya dudes
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 equal footing with all the other RFC authors. What more of a voice did you want? Sure, people play at politics; ignore them, they're not important. While people play at politics, that *by no means* implies that Perl does. -- The debate rages on: Is Perl Bachtrian or Dromedary?
Re: IDEA: lexically scoped subs anyone
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 self-referential
and mutually referential lexical subs: how to
declare the subs?
--
Um. There is no David conspiracy. Definitely not. No Kate conspiracy either.
No. No, there is definitely not any sort of David conspiracy, and we are
definitely *not* in league with the Kate conspiracy. Who doesn't exist. And
nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
Re: IDEA: lexically scoped subs anyone
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)
> (odd? (lambda (x) (if (= x 0) nil (even? (- x 1))
> (even? 11))
>
> [No, this is not a good way to write these functions.]
>
> I'm unsure how to write this Perlishly.
Hm. How about something like this:
{
my sub odd;
my sub even;
sub odd { return !even(shift)}
sub even { return !odd (shift)}
}
--
It took the computational power of three Commodore 64s to fly to the moon.
It takes a 486 to run Windows 95.
Something is wrong here.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
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 consider and evaluate. In a perfect world, "the community" can agree on a "right direction", and we'd be following that. As we've seen, not only is it difficult to agree, but even agreeing on a direction is no guarantee that it's right. -- "I find that anthropomorphism really doesn't help me with a place full of bugs." -- Megahal (trained on asr), 1998-11-06
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
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. It does seem to be pretty well bourne out in reality for a myth, doesn't it? (Incidentally, has anyone noticed that John Porter and I appear to have *completely* different opinions about *everything*?) [1] Unless you consider a committee of three plus editorial staff. -- Given an infinite amount of monkeys an infinite amount of time, an infinite amount of drafting supplies, and an infinite amount of crack, they'd come up with Downtown Chicago. -- David Jacoby, in the monastery
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
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, > > I presume you haven't ever heard the famous epigram to which I alluded? I have, I was just doubting its veracity. > I hate to have to disagree with you on this, Simon, ;-), > but when I agree with you -- which is often -- there's usually > not much I can add, so I don't. You go, boy! Argh. You just *had* to agree then, didn't you, just to be awkward? :) -- A Law of Computer Programming: Make it possible for programmers to write in English and you will find that programmers cannot write in English.
Re: List Comprehensions (from Python)
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
Re: What will be the Perl6 code name ?!!
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 had an animal on the cover, but that was me. -- Overall there is a smell of fried onions. (fnord)
Re: What will the Perl6 code name be?
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 someone loses an eye. Then it's a sport!
Re: What will the Perl6 code name be?
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 I owned the M$ division that built Lookout and SexChange, I'd trade it for a dog, and then I'd shoot the dog. - Mike Andrews, asr.
Re: What will the Perl6 code name be?
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 binaries directly requires rather more carnal > knowledge of the OS/processor pair than something like an interpreter or > C-code-spitter does. Right, right, but once we've got a nice interface to the op tree - which may be something like B::, or maybe a low-level C API - we can, and probably should, encourage people to play with it. A C-code-spitter is another kettle of fish altogether; as you know, the current things like B::C and B::CC spit out a state dump of the op-tree and then an interpreter. This is cool enough, but it isn't what people want. What they want is a translator, rather than a compiler, and this is slightly more tricky. However, due to Nat's terrible influence, he suggested to me at YAPC::Europe that someone should try writing one.[1] I'm working on something I'm calling B::Translate for Perl 5 which does just this; it's basically a variant of B::Deparse which spits out C instead. It's a really tricky job, which reminds me of all the things I dislike about C, but it's getting there, slowly. [1] He also mentioned that that's the sort of thing ActiveState should pay someone to do, which I mention on the off-chance someone interesting is listening. :) -- ... though the Japanese must be the most stupid people... I'm sure I read somewhere that Tokyo has the densest population in the world... - Gid Holyoake, sdm.
Re: What will the Perl6 code name be?
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 separate shared libraries, and dynamically replaceable. (or
> at least done with a quick relink)
Yes, yes, yes, yes, yes, yes, yes, yes, yes. Incidentally, I think that's a
good idea.
> (Or a C source module, or ties into the GEM
The Atari ST to my right just perked up.
> What's this piece do that B::C or B::CC don't do? I'm confused here.
It doesn't embed an interpreter. It outputs "native" C.
#!/usr/bin/perl
print "Hello world\n";
translates to
int
main (int argc, char **argv)
{
#line 2 "hello.pl"
printf("%s", "Hello world\n");
}
--
By God I *KNOW* what this network is for, and you can't have it.
- Russ Allbery, http://www.slacker.com/rant.html
Re: What will the Perl6 code name be?
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: "After three days without programming, life becomes meaningless." -- Geoffrey James, "The Tao of Programming"
Re: What will the Perl6 code name be?
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 those BEGIN blocks are *supposed* to be instructions to the compiler. > Runtime string eval, do, and require are a serious pain in the butt. > They're the one set of things that'll force a real interpreter into a program. *nodnod*. This is really tricky; if there's no eval in the program, we can make all sorts of interesting optimizations: forego the whole SV process, and just use ints and char*s and whatever. If there's an eval, you've got to throw everything back into Perl-space, embed an interpreter, and all that jazz. Yes, it sucks hard. But Perl *is* an interpreted language, like it or not. -- "Jesus ate my mouse" or some similar banality. -- Megahal (trained on asr), 1998-11-06
Re: What will the Perl6 code name be?
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. -- David Jones
Re: What will the Perl6 code name be?
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. > What about introducing a pragma which either (a) promises not to use such > things, or (b) throws an exception if the program does use such constructs, > and say "if you want your programs to be compilable (or compile to > something a heck of a lot lighter), say 'use strict "compilation"' or > whatever"? Why bother? We can tell if such a thing is going to be introduced from the op tree. It only matters when we want to compile things, and I'm guessing that's going to be the minority of cases. When Joe Random writes his one-liner, I don't want to interfere with him. -- If God had a beard, he'd be a UNIX programmer.
Re: TIL redux (was Re: What will the Perl6 code name be?)
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-inventing .NET. Why? -- Do you associate ST JOHN'S with addiction to ASIA FILE? - Henry Braun is Oxford Zippy
Re: TIL redux (was Re: What will the Perl6 code name be?)
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, in any sense of the word, true? I mean, given three-address code, I find anything equally difficult to generate. I don't see anything that distinguishes this from the ordinary process of generating code with a runtime library and a stack. -- DEC diagnostics would run on a dead whale. -- Mel Ferentz
Re: new to perl
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 go screw itself. - Linus Torvalds
Re: What will the Perl6 code name be? (again)
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."
Re: We should have some YAPC talks on Perl 6
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't, I will. But I'd rather you could, so we two can sit down
and cabal this thing into existence.
--
[Bastille Linux] Of course, if we consider the relative ease with which
the historical Bastille was taken by a bunch of peasants, maybe there's
not much difference between the two. - Jonathan Byrne.
Re: Why shouldn't sleep(0.5) DWIM?
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 > > hopefully, make it load faster. > > I agree > > dbmopen() already loads AnyDBM_File to do the real work without the > user (or script) knowing, so this idea could be extended. What an excellent idea. http://dev.perl.org/rfc/315.html -- Testing can show the presense of bugs, but not their absence. -- Dijkstra
Re: Why shouldn't sleep(0.5) DWIM?
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 things have changed is an "added burden" over remembering that $x things have changed. > "Perl should remain Perl" (once known as RFC 0) is bogus If you want things that *aren't* Perl, you know exactly where to find them. -- I see ADA as a larger threat than communism at this point in time -- Ted Holden
Re: Why shouldn't sleep(0.5) DWIM?
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 good reason for having them there. So, since we're starting from scratch, we're not getting rid of them. We're merely not putting them in. -- God gave man two ears and one tongue so that we listen twice as much as we speak. -- Arab proverb
Re: Why shouldn't sleep(0.5) DWIM?
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 with the "Keep Perl Perl" non-argument. No. -- [It is] best to confuse only one issue at a time. -- K&R
Re: Really auto autoloaded modules
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 containing that function. But that *is* what we do with glob and the heavy unicode things! Anyway, I see your point. I shall have a think about it tonight. -- Writing software is more fun than working.
Re: Really auto autoloaded modules
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 shot at formalizing the system? Well, this is currently called XS. (Although you can't do user-defined ops in XS, but it's *theoretically* possible. The margin of this email is not wide enough, etc.) Are you asking for someone to define a replacement for XS, or just a method for doing what we currently do with, say, glob or the heavy unicode things? -- If they can put a man on the moon, why can't they put them all there?
Re: Why shouldn't sleep(0.5) DWIM?
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 > opinion, thinks would cause Perl to no longer be Perl. I take great exception to the implication that my opinions are humble! John, if you're going to out and out insult someone, do it decently. Or elsewhere. Preferably elsewhere. -- The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. -Kernighan, 1978
Re: Really auto autoloaded modules
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! :) -- I'm not going into LMH, there might be GECKOS. - Henry Braun is Oxford Zippy
Re: Really auto autoloaded modules
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/html/ch02.html#S-PID-SID-CATALOGS -- Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea.
Re: assign to magic name-of-function variable instead of "return"
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 (`What, I'm assigning to the *function*?
Huh?') and then C came along and then the name of the function meant its
address. Let's not even more scary. Assigning to barewords? Blurgh. At the
very least, make @subname and $subname special lexicals.
> We could even define a new line noise variable
Oh great. :(
--
Timesharing just doesn't work. -K. Thompson, 1982.
Re: assign to magic name-of-function variable instead of "return"
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 campus the UNIX system has proved to be not only an effective software tool, but an agent of technical and social change within the University. - John Lions (U. of NSW)
Re: Really auto autoloaded modules
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
> >standard library!!!
>
> Very *bad* idea. It sounds nice, but using a remote module without any sort
> of control is just begging for trouble.
Whether it's a good idea or a bad idea is largely irrelevant; the
purpose of -language is to decide whether or not it should be possible.
And given that it's prefectly possible in Perl 5 anyway, I don't see
why it's even being mentioned.
--
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."
(By [EMAIL PROTECTED])
Re: Really auto autoloaded modules
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
Re: JWZ on s/Java/Perl/
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 Pitch Black
http://www.despair.com
Re: JWZ on s/Java/Perl/
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
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
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_temperature();
bless {}, shift
}
sub DESTROY {
Reactor->increase_core_temperature();
}
--
diff: usage diff [whatever] etc.
- plan9 has a bad day
Re: perl6-language needs admin help too :)
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 everything (You're getting this, like it or not. :) * One weekly summary of each list * One weekly summary of each list feeding into a weekly summary of everything * Something else? -- linux-2.3.99-pre9.tar: limbo program - plan9 has a bad day
Re: End-of-scope actions: do/eval duality.
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/~ask/als/larry-als.txt, you can find it in > http://dev.perl.org. Read the fifth paragraph under `[Simplifications]'. Having read that many times over, I agree with Abigail. You can't just magically invoke Larry and expect that to prove your point. Or prove that you have a point. -- For me, UNIX is a way of being. -Armando P. Stettner
Re: Closures and default lexical-scope for subs
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, which is why we gave Larry the job. That being done, I'm not entirely sure why people are continuing to argue about these things. :) -- "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." (By [EMAIL PROTECTED])
Re: The binding of "my" (Re: Closures and default lexical-scope for subs)
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 realistic simulations involving a sledge hammer and a common laboratory frog, we can assume it will be pretty bad. - Dave Barry
Re: The binding of "my" (Re: Closures and default lexical-scope
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 dumb. That's not to say it's offensively smart, either. :) -- "Jesus ate my mouse" or some similar banality. -- Megahal (trained on asr), 1998-11-06
