Re: Closures and default lexical-scope for subs
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 an error, a warning, or DWIM. Especially: Personally, I don't think so. GetOptions (foo = \my $foo, bar = \my $bar); and tie my $shoe = $tring; are just way too practical to suddenly require more hoops. I don't want to DWIM this. Would it be so bad to have to type GetOptions (foo = \my ($foo), bar = \my $bar); If you're really all for maintainability, then surely you mean: GetOptions (foo = \my ($foo), bar = \my ($bar)); otherwise some dumb hacker (eg. You, two weeks later) could come to add annother pair of args by sticking C, baz = \my $baz into the args list... tie my ($shoe) = $tring; if we made 'my' consistent with all other functions that take lists (yes-I-know-it's-not-a-function)? Do you not *care* how ugly you're making something that was once compact, expressive and elegant? And if it's not a function then WTF do you want to make it look like one, potentially sowing more confusion.
Re: End-of-scope actions: Toward a hybrid approach.
Incidentally, I just implemented pre- and post- handlers on subroutines
in pure Perl 5, without any changes to the language. Interesting, huh?
sub foo { print "Bar\n"; }
append_to_sub {print "After!\n"} foo; # Perl 5.6.x (\) syntax
append_to_sub {print "After!\n"}, \foo; # Perl 5.6 syntax
foo();
Bar
After!
This actually came as a side-track to something else I was doing which was to
make some subroutines appear like builtins; (available from all packages)
I'll put Sub::Versive on CPAN when I've done *that*.
--
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
The Unlambda Programming Language
"currying" used in a fascinating context: an experimental language in which http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/#tut everything is a unary function. Multiple-argument functions are defined in such a way that the function takes the first argument and returns a function that takes the second.
Re: The Unlambda Programming Language
On Mon, Feb 19, 2001 at 01:17:56PM -0600, David L. Nicol wrote: "currying" used in a fascinating context: an experimental language in which http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/#tut Oh, nooooOOO!! Those with small children, heart conditions or a weak stomach, please look away. The following Unlambda program calculates and prints the Fibonacci numbers (as lines of asterisks) ```s``s``sii``s`kk`ki`ki``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s``s`ks` `s`kk`ks``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s``s`ks``s`kk`ks``s``s`k s``s`kk`kk``s`kk`kr``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s``s`ks``s`kk `ks``s``s`ks``s`kk`kk`ki``s``s`ks``s`kk`kk``s`kk`k.*``s``s`ks``s`kk`kk ``s`kki``s``s`ks``s`kk`kk``s`kki``s`kk`ki``s``s`ks``s``s`ks``s`kk`ks`` s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s`kk`kk``s`kk`k``s``s`ks``s``s`ks` `s`kk`ks``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s`kk`kk``s`kk`ks``s``s`k s``s``s`ks``s`kk`ks``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s`kk`kk``s`kk `ks``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s`kk`kk``s`kk`kk``s``s`ks``s` kk`kk``s`kki``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s`kk`kk``s`kk`kk``s` kk`ki``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s``s`ks``s`kk`ks``s``s`ks`` s`kk`kk``s`kk`ks``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s``s`ks``s`kk`ks ``s``s`ks``s`kk`kk``s`kk`ks``s``s`ks``s``s`ks``s`kk`ks``s``s`ks``s`kk` kk``s`kk`kk``s``s`ks``s`kk`kk`ki``s``s`ks``s``s`ks``s`kk`ks``s``s`ks`` s`kk`kk``s`kk`kk``s`kk`ki``s``s`ks``s`kk`kk``s`kk`ki``s``s`ks``s`kk`kk `ki``s`kk`ki (Line breaks, as all whitespace in fact, are optional and arbitrary.) ;) (I know, I know. Its the principle of the thing that counts) -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Appropriate perl6-language behaviour
[ Cc: perl6-language, [EMAIL PROTECTED] ] Yaphet, As you may be aware, I've been a bit absent from p6-language lately, as I've been moving to Canada and rather busy. So I apologise for not having brought this up earlier, which I really should have done as Perl 6 Language working group chair and list mom. Your behaviour on the p6-l list has been totally unacceptable. Personal attacks and name calling are *not* appropriate to this forum, and even a brief examination of your recent posts shows that this is a common form of communication from you. Likewise, the Perl 6 lists are for those who are working *on* Perl 6, not *against* it. If you don't like Perl, go play somewhere else and leave this space for those who are trying to achieve something. This is a formal warning. If you do not refrain from abusing Perl 6 contributors and Perl itself on-list, you will be blocked from posting to the list. This is effective immediately, allowing only for the time it may take you to read this email (I understand that you may not read this before you post more flames). Other Perl 6 readers, please prod me if Yaphet's being abusive again. I regret that I may not be able to keep right up to date with the list, as I'm still very busy, but I will try to keep an eye on things and deal with this appropriately. And of course, to everyone, please keep in mind the appropriate response to trolls: ignore them. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "The phrase "Login to www.clue.org and issue the GET command" springs to mind..." -- Tanuki the Raccoon-dog in the monastary
Re: End-of-scope actions: Toward a hybrid approach.
On Mon, Feb 19, 2001 at 06:46:11PM +, Simon Cozens wrote: This actually came as a side-track to something else I was doing which was to make some subroutines appear like builtins; (available from all packages) I'll put Sub::Versive on CPAN when I've done *that*. It's up. Enjoy. -- Use an accordion. Go to jail. -- KFOG, San Francisco
Re: End-of-scope actions: Toward a hybrid approach.
Simon Cozens wrote: Incidentally, I just implemented pre- and post- handlers on subroutines in pure Perl 5, without any changes to the language. Interesting, huh? Yes. And the modules on CPAN that already do this are interesting too. -- John Porter
Re: End-of-scope actions: Toward a hybrid approach.
On Mon, Feb 19, 2001 at 09:00:11PM -0500, John Porter wrote: Simon Cozens wrote: Incidentally, I just implemented pre- and post- handlers on subroutines in pure Perl 5, without any changes to the language. Interesting, huh? Yes. And the modules on CPAN that already do this are interesting too. Oh, bother. Oh well, I've got builtinify (which was actually the point of the exercise) and they haven't, so I'm happy. :) -- Intel engineering seem to have misheard Intel marketing strategy. The phrase was "Divide and conquer" not "Divide and cock up" (By [EMAIL PROTECTED], Alan Cox)
RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)
much deleted As much as I'd like to respond to some of these points, I'll refrain from it now, I'll let my RFCs speak for themselves. Speaking of which... apologies in advance for cross-posting this, but I wanted to get the largest audience possible... I won't do it again. At least not in the forseeable future.. ;-) Ed RFC 362 --- =head1 TITLE The RFC project should be ongoing and more adaptive. =head1 VERSION Maintainer: Edward S. Peschko [EMAIL PROTECTED] Date: 19 Feb 2001 Mailing List: [EMAIL PROTECTED] Number: 362 Version: 1 Status: Developing =head1 ABSTRACT The RFC process should not have had an artificial deadline; it should be an adaptive process that should last the entire development cycle of perl6 and perhaps after. =head1 DESCRIPTION I did a brief audit of all of the RFC's, and wheras they were a good start, they are hardly the end-all-be-all for perl6. There were gaps in functionality, a variance in the quality of the RFC's, and not enough emphasis on implementation. In addition, the discussion on the list did not seem to wend its way back into the RFC's themselves. Mark Dominus went so far to post a critique of the entire process: http://www.perl.com/pub/2000/11/perl6rfc.html and to conclude that the whole "RFC's process" was pretty much a waste of time for the quality of RFC's produced. Well, that's one view - but it neglects to recognize: =item 1. that without an RFC process in place, old ideas and discussions will rehash themselves on mailing lists ad nauseum. =item 2. that RFC's are a good starting point for people unfamiliar with with discussions/issues on the mailing list. =item 3. that RFC's are a good starting point for documentation. =item 4. that this is perl's first attempt at organizing ideas like this. Hence, we are newbies at this and are bound to make mistakes the first time round. However, there is one aspect in which I agree with him. That, as it stands, the RFCs are incomplete, lack encorporation of discussion, and seem to be 'out of touch' with the rest of the RFCs (to some extent). But that just points out to me the validity of point #4 above; we are new at this. We would get better as we go along. In addition, right now (as of February), I get the sense on the mailing lists that people don't really know what to do next. 'Wait for Larry' seems to be the order of the day, and we have been waiting for a while. Instead, I think that the doors to the RFCs should be re-opened, and that they should be bulletproofed. The next four RFCs suggest methods on how to improve the RFC process and the quality of RFCs: RFC 363 - Anyone posting a new RFC should have read all of the existing RFCs first. RFC 364 - There should be a web interface for people to interactively comment on RFCs. RFC 365 - There should be a rating system for RFCs. RFC 366 - There should be a culling system for RFCs, a way to distinguish quickly between withdrawn RFCs and RFCs in process. (ps -- no, I haven't written these yet. But if this RFC is acted upon, I reserve those numbers in advance. ;-)) =head1 IMPLEMENTATION Not really an implementation thing, more of a philosophy and process. =head1 REFERENCES http://www.perl.com/pub/2000/11/perl6rfc.html http://www.perl.com/pub/2000/11/jarkko.html
Re: End-of-scope actions: Background.
On Mon, Feb 12, 2001 at 01:58:35PM -0700, Tony Olekshy wrote: Hi, it's me again, the guy who won't shut up about exception handling. I'm trying, I'm catching. -- "Dogs believe they are human. Cats believe they are God."
Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)
At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote: RFC 362 --- =head1 TITLE The RFC project should be ongoing and more adaptive. It's my understanding that this is, in fact, the plan. The only reason things have paused (and it is a pause, not a stop) is that we're waiting for Larry to take what's been done so far and build something resembling a coherent base we can implement. After that's done then we'll have something to work from, which is a good thing. If we don't ever stop, ponder, and implement, the RFCs will be just another go-round of intellectual masturbation. (and we *really* don't need to go there...) Yeah, it means the process will be bursty, but that's just the nature of the beast. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
