Re: The distinction between do BLOCK while COND and EXPR while COND should go
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
It might be worthwhile enough to kill
sub fn { return (7,8,9,10) }
$x = fn(); # $x == 10
TC But this happens many places. What about @foo[4,1,9,-2]?
TC It's just a listish thing. One should learn.
I don't want that to change. I simply want that return (I'm not sure
how to phrase this) be able to return only a scalar or an aggregate.
It should be immune from having a scalar context pushed through from
the caller and change the commas from a list seperator into the comma
operator.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 178 (v1) Lightweight Threads
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes: Not unless it is so declared my $a :shared. SWM Sure it is. SWM Here are some more examples. SWM Example 1: Passing a reference to a block-scoped lexical into a thread. Depends on how locking/threading is designed. There is a fundemental issue on how values are passed between threads. Does the value leave one thread and enter the other or are they shared. The idea tossed around -internals was that a value that crosses a thread boundary would have a wrapper/proxy attached to handle the mediation. The mediation would be activated only if the value is passed via a shared variable. In your case the shared variable is the argument being passed through the thread creation call. SWM Example 2: Declaring one subroutine within the scope of another If we don't require a :shared on variable anything and everything has to have protection. If you want the variable to be shared declare it. SWM Example 3: Closures (Ken's example) Aha, I get it. -internals has been assuming that one _must_ specify the sharing. You want it to be infered. I think that's asking for too much DWIMery. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 39 Perl should have a print operator
Perl supplies an operator for line input - angle brackets. This is no analogous operator for output. I propose "inverse angle brackets": How about quotes? A quoted lhs expression could mean print. A quoted lhs expression preceded by a file handle could mean print to filehandle. Tom Christiansen's complaint seems irrelevant to me because a print statement is already ugly in that visually interminable way. "expr"; could be the special case of the more general print//; print[]; print(); parallel to the m//; and other such constructions. Hm, maybe then I'd suggest shortening 'print' to 'o' for output: o//; ...etc... As a corollary maybe I'd suggest similarily regularizing input: i//; i[]; i(); with the traditional special case of: ; I know, parallel construction for not really parallel item. "i" and "o"! Hm, I guess this may run afoul of the qq() and q() syntax, or at least gets kind of mushed up with them. Well, what the heck, if they are on the lhs...? The only losers would folks who have used quotation marks of various kinds as multi-line comment delims. (...me) The other only losers would be those who have stuck evaluatable exprs inside lhs quoted stuff to be exec'd for their side effects, yuck. The save keystrokes at any cost people should love it (though I am always puzzled why they don't use editor macros then). The hate context people will hate it. Why such a short timeline on these discussion groups? It's summer, yall. -- -ken rich "Strong typing is for people with weak memories." --Compucius[EMAIL PROTECTED]
Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors
Damian Conway wrote: * invoke some other hierarchy of automagic methods (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or REINCARNATE
Re: RFC 187 (v1) Objects : Mandatory and enhanced second argument to Cbless
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: Perl6 This RFC proposes that the second argument to Cbless be made Perl6 mandatory, and that its semantics be enhanced slightly to cover a Perl6 common, ugly, and frequently buggy usage. Yes! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 190 (v1) Objects : NEXT pseudoclass for method redispatch
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: Perl6 This RFC proposes a new pseudoclass named CNEXT. Perl6 This pseudoclass would provide a way of correctly redispatching a method Perl6 or an autoloaded method. Yes! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
On Sat, Sep 02, 2000 at 12:16:48AM -0400, John Tobey wrote: I agree with Michael that SETUP should be BLESS. You argue that it Oops, I mean Nate. Sorry, Michael! -John
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
Michael G Schwern wrote:
Derived classes will never have to override a base's implementation,
and all member variables should be private, and everyone will always
use an accessor, and the UN will bring about world peace, and as long
as I'm wishing for a perfect world, I'd like a pony. ;)
I'm still not totally convinced that its so horrid to make the
File::LockAndKey DESTROY call $self-SUPER::DESTROY manually... but it
does break encapsulation.
I'm inclined to agree here. I thought about this overnight, and I'm
nervous about it again. It doesn't seem that it's that hard to add a
single line to your SETUP or BLESS or whatever method that calls
SUPER::SETUP.
Remember, for all other methods you'd still have to do this manually. If
you wanted to modify ADD or STORE, for example, just tweaking a few
things, you'd have to manually call SUPER::STORE. I'm not convinced that
this proposal saves enough typing to justify the problems that Michael
mentions.
Plus, what if you want to call a SUPER::'s DESTROY *not* at the start or
end?
sub DESTROY {
my $self = self; # :-)
# do a bunch of stuff here
$self-SUPER::DESTROY(@_);
# do a bunch more stuff here
}
It seems like this RFC enforces stuff that makes subclassing
unnecessarily hard in some cases. At the very least, there should be a
way to turn this off:
sub SETUP : nocascade { }
But then, if you're going to turn it off, why not just leave as-is and
have the person turn it on manually by calling SUPER::? Your other RFC
proposes calling NEXT:: manually, so the same philosophy I think should
apply here.
You could still have hooks for BLESS and REBLESS in bless(), but just
make people manuallly call SUPER::BLESS and SUPER::REBLESS if they want.
People doing Perl OO understand SUPER:: already.
-Nate
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
On 9/2/00 11:34 AM, Nathan Wiger wrote: It doesn't seem that it's that hard to add a single line to your SETUP or BLESS or whatever method that calls SUPER::SETUP. I'm pretty sure one of the big points about the system described is that it ensures both that there's always a predictable and automatic chain of events for SETUP/DESTROY (without requiring the programmer to create and document his own bug-free implementation) and it ensures that each routine is called only once, regardless of multiple inheritance paths. And I still vote for BUILD, SETUP, or MAKE over BLESS. The whole notion of blessing is non-obvious enough already. But bless() does the blessing. Those chained routines do the INITing, or the BUILDing, or the SETUP. They don't do the blessing. I think the conceptual hurdle for newbies will be the order of dispatch, not the name of the routine that get called after blessing. Naming it BLESS too greatly favors the first week of Perl use, punishing experienced programmers by making them do all their setup and initialization in routines with a fanciful and illogical name. After several years of this, we'd see 50 Perl 7 RFCs about renaming BLESS to BUILD, SETUP, or MAKE. Mark my words! ;) Actually, I'd be happy with an RFC for an entirely new method of object creation and identification that has nothing to do with bless (but I don't expect one and I'm not clever enough to come up with something myself that'd sway the Perl public...) -John
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
The whole notion of blessing is non-obvious enough already. It's the benedictory (con)not(at)ion of blessing, not the bless()ing itself that so confuses people, I think. It bless() were instead named something like mark stamp label brand retype denote notate entype mktype nominate emblazon classify annotate designate authorize methodize This might not be so confusing. Most of those, however, are longer to type than bless. --tom
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors
On 9/2/00 12:12 PM, Nathan Wiger wrote:
I think this RFC could work for this, but as I noted in a private email
to Damian I'd rather see a whole new keyword made, maybe "setup"?
sub new { setup {}, @_ }
sub SETUP { ... }
Sure, but does setup() bless? That's the question... :) In other words,
are we just renaming Damian's bless or is this a whole new way to mark
something as an object?
One thing nobody's brought up is this: What if you decide you want the
standard Perl 5 bless behavior, and you want to tweak the order of
calls. So, you don't define a SETUP. BUT, the author of a module you're
inheriting from defined a SETUP, not to your knowledge? This gets called
automatically by bless(), with no way to override it, either making you
manually undo it all or decide not to subclass it anymore. This is bad.
No worse that the current situation in which you have no clue what the
guy you're inheriting from expects. Better to have SETUPs called
below you than to not even know that there's some terribly important init
stuff that needs to be done by a parent class and that you neglect to
manually invoke. Determined individuals can always stop it from
happening by nefariously blanking out sub ParentClass::SETUP {}
I think the RFC would be fine intact with the change that a new keyword
"setup" should be added that:
1. Automatically blesses stuff
2. Recursively calls SETUP in the method described
That way, Perl 5 bless remains unchanged (good), and we get all the new
features Damian's proposing (also good). This RFC is a *big change*. I
think it deserves a new keyword.
I'd buy that I guess.
-John
Re: RFC 188 (v1) Objects : Private keys and methods
private $self-{data} = $derdata;
should be $derdatum here?
Yes. Thanks.
Damian
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
I'm still not totally convinced that its so horrid to make the File::LockAndKey DESTROY call $self-SUPER::DESTROY manually... Believe me, it is in a large, deep, and/or MI hierarchy! but it does break encapsulation. Exactly. If you can figure a way out of the dilema I proposed above, I suppose this makes sense. Easy. Don't let File::Lock::Mac inherit from File::Lock. Have it *delegate* to File::Lock instead. See my forthcoming Cuse delegation RFC. Damian
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors
The "multiple inheritance paths" one is good. I like that part a lot. But the rest makes me really nervous if there's no way to override or change it. There is. I'll try and get the Cuse delegation RFC out today. One thing nobody's brought up is this: What if you decide you want the standard Perl 5 bless behavior, and you want to tweak the order of calls. So, you don't define a SETUP. BUT, the author of a module you're inheriting from defined a SETUP, not to your knowledge? This gets called automatically by bless(), with no way to override it, either making you manually undo it all or decide not to subclass it anymore. This is bad. Delegation support will make "not subclassing" it trivial. Damian
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
On Sat, Sep 02, 2000 at 03:18:06PM -0400, Mike Lambert wrote:
In certain cases, like the one in which you
proposed, you'd want to explicitly bypass the parent DESTROY.
sub DESTROY {
my $self = shift;
$self-UNIVERSAL::DESTROY(@_);
}
would skip the automatic chaining because the function contains an
explicit call to a superclass's DESTROY.
As you said, sounds difficult to implement and difficult to document.
Too much magic.
In cases of more complex class hierarchies, you can explicitly call
one parent class's DESTROY, and skip anothers.
Bad, bad, bad. Busts encapsulation, poking around in your parent's
hierarchy.
Just to make it clear, I agree, in principle, with chaining DESTROY
and SETUP. I'd just like to see all the caveats cleared away first.
We already have a system that kinda works, there's no point in
replacing it with another that only kinda works.
Also, its not entirely clear why method chaining is desired only for
constructor and destructors. What about every other method?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
BOFH excuse #177:
sticktion
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
Also, its not entirely clear why method chaining is desired only for constructor and destructors. What about every other method? Constructors and destructors are special. They're not about *doing* something; they're about *being* (or not being) something. A "doing" method *may* wish to make the object do everything its hierarchy allows it to do: that's why I proposed CNEXT. A "being" method *must* make the object be everything its hierarchy requires it to be: that's why I proposed hierarchical constructors and destructors. Damian
Re: RFC 114 (v2) Perl resource configuration
Uri Guttman [EMAIL PROTECTED] writes: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: many systems allow for a global/local startup file for various reasons. i see a potential use of this in perl but i don't see the specific use yet. build it they will use it. TC But Perl is not an interactive shell! Can you imagine if a C TC compiler allowed arbitrary amounts of text to be pre-included and what about the proposals for an interactive perl? maybe they should support this. An interactive Perl can certainly read some options, just like a debugger. This is not specific to Perl, of course; GDB, for one example, also reads configuration files when loading. But that doesn't mean GCC reads a configuration file to tell it what type of C code the system administrator has decided to mandate! Configuration files for Cperl -d, an interactive Perl, Cperldl, and any other application written in Perl are a nice idea (one that TomC seems to support). This has nothing to do with wanting to configure the language itself. [...] -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 11:40:13PM -0400, Uri Guttman wrote: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC But Perl is not an interactive shell! Can you imagine if a C TC compiler allowed arbitrary amounts of text to be pre-included and what about the proposals for an interactive perl? maybe they should support this. That can be handled totally differently. Shell::Config or something. Similar to CPAN::Config. So the basic problem here, leaving all the minor problems aside, is we have no concrete use for this feature. There's been a few half-hearted attempts at things this might be useful for maybe, but it all boils down to "somebody will find it useful to do something somewhere." I'd suggest we put a hold on further discussion about caveats and implementations until someone really justifies this thing. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would be normally be terminated by detonation. -- Larry Wall in [EMAIL PROTECTED]
Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))
Tom Hughes wrote:
For example, in Perl you have for a long time been able to do this:
($one, $two) = grep /$pat/, @data;
However, what currently happens is grep goes to completion, then
discards possibly huge amounts of data just to return the first two
matches. For example, if @data was 20,000 elements long, you could
potentially save a good chunk of time if you only had to return the
first and/or second match, rather than finding 1000 only to throw 998
away.
This could fall out of using iterators in the core but without
grep itself having to know anything about the left hand side.
...
The only problem with this scheme (and indeed I suspect with
yours) is if the match expression has a side effect. This is
even more of a problem when trying to apply the same optimisation
to map because of the widespread use of map in a void context
to apply a side effect to the elements.
RFC 123 'Builtin: lazy' describes a syntax for explicitly stating that your
operation does not have a side effect, and requests that a 'lazy
list'/iterator be used. It mentions grep as an example:
quote
What if adding laziness to a list context was up to the programmer
and passed through functions that can support it:
for (lazy(grep {$h{$_}-STATE eq 'NY'} keys %h)){
$h{$_}-send_advertisement();
};
would cause a lazy list is passed to Cfor, and increment of
the object's "letters_sent_total" field might break the iteration.
for (grep {$h{$_}-STATE eq 'NY'} lazy(keys %h)){
$h{$_}-send_advertisement();
};
causes a lazy list to be passed to our filter function Cgrep, saving
us from allocating the entire Ckeys array. CGrep is still in
the default busy context, so it returns a busy array, which Cfor
can iterate over safely.
/quote
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
"Tom" == Tom Christiansen [EMAIL PROTECTED] writes: Tom Wherever you think you need one of these, try to think again. Either Tom it's already in list context, in which case it's silly to put in Tom the list thing, or else there's always a better way to accomplish Tom whatever you're trying to do--which, as I have shown, can vary Tom greatly. Tom This proposal should be dropped. Yeah, what Tom said. Any time I've need a "single element" of some "list value", I've had to think about which single element to pull out. Since there's no general rule for converting a scalar to a list (there's only twenty or so specific rules :), there's no consistent way to take this coerced "list in a scalar context" and wrangle it back to a scalar! "list" keyword. Just say no. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 114 (v2) Perl resource configuration
On Fri, 1 Sep 2000, Tom Christiansen wrote: it can be used for system specific @INC paths without recompiling perl That's what PERL5LIB is for. PERL5LIB is available for the individual user to use, set, unset, change, etc., at will. As sysadmin, you can't set it in /etc/profile and be sure that your setting will stick. Actually, you can't even guarantee that every process will be run under a shell that sources /etc/profile or indeed under a "shell" that sources any configuration file at all under /etc. Even if you could, however, there's still a maintenance issue. For "configuring" one package, perl, does it really make administrative sense to have to maintain N /etc/*profile files (one for each possible shell?) This would mean that every shell upgrade could potentially require manual intervention to retain the perl customization. If (please note I said "If" here--I'm not arguing for or against the proposal) it would be useful to configure perl, then I strongly would argue that such configuration ought to be localized to just a very few files under perl's control. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[OT} Universal shell configuration
It's called meta shell
ftp://www.guug.de/pub/members/truemper/metash
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";{$F[0]};sub t{*t=sub{};
return if rand().5;$_="Vg'f abg lbhe ghea lrg, abj tb.";{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}v;}{$_++;$_--;$_||=4;
if($_2||($_212)){$_="Vainyvq ragel";{$F[0]};last;}t;$0-=$_;$_="Lbh jva";
die({$F[0]}) if !($0-1);$0-=$0%2?$02?2:1:$0=5?$02?3:1:rand.5?1:3;
$_="V jva";die({$F[0]}) if !($0-11);}v __END__ http://pthbb.org/
MOTD on Setting Orange, the 26th of Bureaucracy, in the YOLD 3166:
Learnin' to fly but I ain't got wings. Comin' down is the hardest thing...
Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))
Here is my suggestion: What if other functions were able to backtrace context and determine how many arguments to return just like split can? I have an RFC on that: RFC 21: Replace Cwantarray with a generic Cwant function Cwant takes a list of strings that describe aspects of the context in which the current subroutine has been called. It returns a list indicating whether or not the current subroutine's call context matches all the aspects specified in the list ... at least one integer element is returned. That integer (the "expectation count") indicates the number of return values expected by the context. Damian
Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))
Here is my suggestion: What if other functions were able to backtrace context and determine how many arguments to return just like split can? I have an RFC on that: RFC 21: Replace Cwantarray with a generic Cwant function Cwant takes a list of strings that describe aspects of the context in which the current subroutine has been called. It returns a list indicating whether or not the current subroutine's call context matches all the aspects specified in the list ... at least one integer element is returned. That integer (the "expectation count") indicates the number of return values expected by the context. Ever consider then having ($a, $b, $c) = FH; or @a[4,1,5] = FH; only read three lines? I mean, how many if any builtins would it make sense to make aware of this, and do something "different"? Seems a bit rare and unimportant -- until one observes how this would also solve the problem of people being confused by this gobbling up their handle: my($line) = FH; --tom
