Re: RFC195: Do not remove 'chop' PLEASE!
On Sat, Jan 27, 2001 at 05:13:23PM -0500, Michael G Schwern wrote:
> On Sat, Jan 27, 2001 at 03:42:43PM -0700, root wrote:
> > I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
> > What does 'chop' have anything to do with 'chomp'?
>
> chop() and chomp() are very often confused due to their similar names,
> similar functionality and the fact that chop() did chomp()'s job
> (poorly) prior to perl5. Nowdays, chop() is very often used where
> they really ment chomp().
>
> Actually, the docs are somewhat to blame for this. perlfunc is loaded
> with chop misuses. Will fix.
>
> The complex nature of the complete chop() is unfortunate, it makes it
> very difficult to reimplement and prototype. The basic version,
> however, isn't hard:
>
> sub chop (;\$) {
> my($var) = @_ ? $_[0] : $_;
> return substr($var, -1, 1, '');
> }
That doesn't modify its arguments (nor does it modify $_).
> Once you start getting into chopping lists and hashes, it becomes
> impossible to prototype.
This one not only modifies its arguments (or $_ when called without),
it also has the right prototype and works on lists:
sub chop (@) {
my $__;
map {$__ = substr $_ => -1, 1, ""} @_ ? @_ : $_;
$__;
}
Aliasing is a cute thing.
Abigail
Re: RFC195: Do not remove 'chop' PLEASE!
On Sun, Jan 28, 2001 at 12:57:07AM -0500, Michael G Schwern wrote:
> On Sun, Jan 28, 2001 at 01:26:09AM +0100, [EMAIL PROTECTED] wrote:
> > On Sat, Jan 27, 2001 at 05:13:23PM -0500, Michael G Schwern wrote:
> > This one not only modifies its arguments (or $_ when called without),
> > it also has the right prototype and works on lists:
> >
> > sub chop (@) {
> > my $__;
> > map {$__ = substr $_ => -1, 1, ""} @_ ? @_ : $_;
> > $__;
> > }
> >
> > Aliasing is a cute thing.
>
> I keep forgetting you can modify @_ in place. However, the prototype
> on chop is beyond Perl's system. 5.6 reports it as undef, but 5.7.0
> says @. Odd. 5.7.0 also adds the additional complexity of dealing
> with hashes. C is supposed to work... and it does (on
> your routine). How does that work? I'd expect %hash to be fed to the
> subroutine as a list.
Aliasing again. They keys are copies, the values aliases.
Abigail
Re: RFC195: Do not remove 'chop' PLEASE!
On Sun, Jan 28, 2001 at 12:59:53PM -0500, Michael G Schwern wrote:
> On Sun, Jan 28, 2001 at 04:28:08PM +0100, [EMAIL PROTECTED] wrote:
> > Aliasing again. They keys are copies, the values aliases.
>
> How bizarre? Why does it work that way?
keys HASH returns copies of the keys, while values HASH returns
aliases the values (new in 5.7).
I don't know why, perhaps so you could modify them easily:
for (values %hash) {s/foo/bar/}
just like you can do for arrays.
Abigail
Re: JWZ on s/Java/Perl/
On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote: > On Sun, Jan 28, 2001 at 08:56:33PM -0500, Michael G Schwern wrote: > > On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote: > > > Uhm, I'm sorry, but that's not good enough. You cannot distinguish > > > between Windows 95/98/ME on one side, and NT/2k on the other, using $^O > > > alone. After all, $^O is just a constant burnt into the executable when > > > perl was compiled. You can run the same perl.exe on all platforms, and > > > indeed, most people do. Yet win9* and NT are different enough in > > > behaviour (e.g. flock) to warrant a test on platform. Er... which is: no > > > go. > > > > Well, fork works on both now, but I see your point. There are ways of > > detecting the OS at run-time under Windows, mostly through MFC junk or > > peeking in the registry. It would probably be good to do it for the > > MacOS versions, too. > > The desire to know the name of the runtime platform is a misdirected desire. > What you really want to know is whether function Foo will be there, what > kind of signature it has, whether file Bar will be there, what kind of > format it has, and so on, whether a feature Zog is present, or what > is the value of parameter Blah. Just knowing the name of the platform > doesn't buy you a whole lot. You want both of course, if only to present the user an error message (s)he can understand. Abigail
Re: RFC195: Do not remove 'chop' PLEASE!
On Mon, Jan 29, 2001 at 10:39:42AM -0500, John Porter wrote:
> Uri Guttman wrote:
> > <[EMAIL PROTECTED]> writes:
> > > Why does it work that way?
> >
> > people wanted access the the actual values of a hash when doing
> > foreach ( values %hash )
> > so they can mung them.
>
> Yes; but the question isn't really "why", it's "how".
> Apparently chop() is specialized internally to detect the
> hashness of its argument, in a way that can't be expressed
> by a prototype.
And I guess every other operator is specialized internally as well?
$ perl -wle '%h = qw /foo bar baz qux/; map {s/.$//} %h; $, = " "; print %h'
foo ba baz qu
$
Abigail
Re: Why shouldn't sleep(0.5) DWIM?
On Tue, Jan 30, 2001 at 05:49:43PM -0200, Branden wrote:
>
> Well, then I propose the same of RFC 48: deprecate time() and create another
> name to refer to the number of seconds since (an epoch) with decimals for
> fractions of seconds. Maybe it could be called now() or timestamp(). Then
> time needn't be on CORE, and can be put together with localtime() and
> gmtime() on Time::Local or anything like it. It could be implemented as:
>
> sub Time::Local::time {
> return int(CORE::now());
> }
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to quick one-liners then.
> Since there will probably a change of mind from programming perl5 to
> programming perl6 (as it will be probably more object-oriented, less
> unix-centric, etc.), I see no problem in telling perl programmers to
> change their implementations:
>
> change:
> : if (my $fh = open(">/tmp/$$".time())) {
> for:
> : if (my $fh = open(">/tmp/$$".int(now( {
> or:
> : my $fh = open("> /tmp/.$progname-$$-" . date(now(), '%Y%m%d%H%M%S'));
> : # creates the file /tmp/.myperlscript-56473-20010130173742
> : # just by looking at it, I can tell it was generated by "myperlscript"
> : # running by process whose pid is 56473, and was generated
> : # at 17:37:42, on january 30th, 2001.
> : # much easier to figure it out than than seconds from 1970...
If time() is there to stay, why bother changing the code? If you insist
on getting file names with year/month/date in them, you can do so now
using localtime(), and if you don't mind to have files with seconds-
since-epoch in the name, why would you mind when perl6 rolls along?
> change:
> : print LOG time() . ": gorkulator borked. Please investigate.";
> for:
> : print LOG int(now()) . ": gorkulator borked. Please investigate.";
> or:
> : print LOG date(now(), '%Y-%m-%d %H:%M:%S')# much better!
> : . ": gorkulator borked. Please investigate.";
> : # in a logfile, the clarity argument is even more valuable...
Write them as:
printf LOG "%d: %s\n" => time (), "gorkulator borked. Please investigate.";
or:
printf LOG "%s: %s\n" => scalar (localtime ()),
"gorkulator borked. Please investigate.";
or:
use POSIX;
printf LOG "%s: %s\n" => strftime ("%Y-%m-%d %H:%M:%S", localtime ()),
"gorkulator borked. Please investigate.";
and gain two things:
1) You get "much better!" without waiting for perl6 to roll along,
2) It doesn't matter whether time() returns an integer or a float.
> Well, at least that's what I think about time. This change wouldn't break
> compatibility, and changing the way we think about this function is a
> healthy thing for our programmer minds. Just because UNIX decided that
> its sleep function would return an int value, doesn't mean we have
> to follow it on our design!
Moving time() out of the core doesn't break compatibility? Changing the
return value of sleep() doesn't change compatibility? What *does* change
it then?
Let's not forget that Perl is a glue language. It heavily interacts
with its environment, other programs and is eager to network with
the outside world. Seconds since 1970 might be as arbitrary as any
other measurement, but that's irrelevant. What's relevant is 30 years
of code that produces and expects timestamps in seconds since 1970.
Deprecating time() in favour of some other arbitrary measurement is
absurd. It might makes sense to have some other functions giving units
since some point in the past next to time() though.
Abigail
Re: Why shouldn't sleep(0.5) DWIM?
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote: > > But the big problem is that there's a lot of stuff that's based off of > time() right now, like stat(), lstat(), etc, etc. When you think of the > cascading effects of changing Perl's timekeeping it gets really, really > sticky. I don't see this problem, unless you plan to write a filesystem in Perl. Surely Perl asks the OS for l?stat() instead of keeping track of it itself? Abigail
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, Jan 31, 2001 at 05:35:03PM -0500, Michael G Schwern wrote: > On Wed, Jan 31, 2001 at 05:23:43PM -0500, Dan Sugalski wrote: > > Pulling out or mangling time strikes me as intensely pointless, and I don't > > see it happening. The socket stuff is really the only core functionality > > that makes any sense to pull out, and that only from an architectural > > standpoint. > > 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? Abigail
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, Jan 31, 2001 at 12:58:01PM +0100, Bart Lateur wrote: > On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote: > > >Why the urge to move it out of the core? Should perl6 be like Python, > >where you first need to do a gazillion imports before you can do anything > >useful? Say goodbye to quick one-liners then. > > 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 wouldn't say it's moving it out of the core on a language list. That's just source code housekeeping. Abigail
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, Jan 31, 2001 at 10:18:19AM -0500, Andy Dougherty wrote:
> On Wed, 31 Jan 2001, Casey R. Tweten wrote:
>
> >
> > Not that there needs to be any discussion on this but IMHO things that
> > can reasonably live outside the core should. I heard somewhere that
> > most people think this way too.
>
> This is why there hasn't been much discussion on it -- there's not really
> much to discuss.
Odd. I'd expect a lot of (pointless) discussion about it.
"It's reasonable for `foo' to live outside of the core!"
"No, it isn't!"
"Yes, it is; I never use it!"
"It should be in the core, I often use it!"
Abigail
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, Jan 31, 2001 at 09:53:23AM -0200, Branden wrote:
> [EMAIL PROTECTED] wrote:
> > > sub Time::Local::time {
> > > return int(CORE::now());
> > > }
> >
> > Why the urge to move it out of the core? Should perl6 be like Python,
> > where you first need to do a gazillion imports before you can do anything
> > useful? Say goodbye to quick one-liners then.
>
> Because with a better built-in that handles fractions of second (if that's
> ever desired, and I guess it is), time() would be deprecated and could
> be easily reproduced as int(now()) or anything like it. It could be in
> a module so that anyone that still wants to use it can find it there. This
> was suggested in RFC 48, that proposes deprecation of localtime and gmtime,
> in favor of the new date and utcdate, and put the old ones in Time::Local.
time() is a very simple call, only a few lines of code in the Perl
source, without much overhead. It's also used quite a lot. There's
hardly anything to gain by removing it, it will break a fair number
of programs, and the alternative requires you to pull in a module.
That doesn't seem a fair trade-off to me.
> The point was, if you're writing new code, you only have to remember that
> when you
> used to have time() in perl5, you should have int(now()) in perl6. That's
> simple
> and doesn't hurt, IMO. If you like time() and think you can't live without
> it, and
> think `use Time::Local "time"' is too long to type, then you should better
> stick
> with perl5!
The point of me was that with the given code, you *don't* need to remember
you are programming in perl5 or perl6, and get the same functionality.
If I would think typing 'use Time::Local "time"' isn't too much to ask to
get basic functionality, I'd be using Python. Things just being there is
a feature of Perl. The "lean-and-clean" market is well covered by other
languages.
> > Moving time() out of the core doesn't break compatibility? Changing the
> > return value of sleep() doesn't change compatibility? What *does* change
> > it then?
>
> Hello... I guess the whole perl6 thing was about breaking compatibility,
> wasn't it? At least, I take for sure we'll have a p52p6 translator to
> translate old code. And for one such translator, importing things from
> Time::Local or even replacing every occurrence of `time()' for `int(now())'
> or whatever is chosen to replace it, isn't complex at all.
It's not complex, but it probably has a lot more overhead than it gains
from not being there. Perl6 doesn't have to be 100% compatible with perl5,
but that's not an invitation to break everything that can be broken.
> > Let's not forget that Perl is a glue language. It heavily interacts
> > with its environment, other programs and is eager to network with
> > the outside world. Seconds since 1970 might be as arbitrary as any
> > other measurement, but that's irrelevant. What's relevant is 30 years
> > of code that produces and expects timestamps in seconds since 1970.
> > Deprecating time() in favour of some other arbitrary measurement is
> > absurd. It might makes sense to have some other functions giving units
> > since some point in the past next to time() though.
> More than one function to do the same thing is A Bad Thing, IMO. It only
> causes confusion.
To make a simple loop, Perl offers you: for, foreach, while, until,
{redo}, map, grep, //g, goto and recursion. Which 9 of them do you
propose to drop from the language so Perl causes less confusion?
There Is More Than One Way To Do It is an official Perl slogan, and
now you are claiming this a *bad* thing? Oh my.
> If a change of mind when writing new software is too much a burden, then,
> I say it again, we should stick with perl5! As Jarkko always quotes:
> $jhi++; # http://www.iki.fi/jhi/
> # There is this special biologist word we use for 'stable'.
> # It is 'dead'. -- Jack Cohen
>
> If old code and old-code thinking are the only thing that prevents us to
> change time() or move it out of CORE, then I believe we should do it yes!
*blink*
Are you claiming the use of time() is dead? Or that stability is a bad
thing?
Abigail
Re: Why shouldn't sleep(0.5) DWIM?
On Thu, Feb 01, 2001 at 11:45:16AM -0500, John Porter wrote: > > I don't think anyone is suggesting that we make changes just > because we can. OBVIOUSLY we would only implement changes > that add something desirable. And the weight of known > desirables is large, or we wouldn't be making perl6. How does removing time() add something desirable? Abigail
Re: assign to magic name-of-function variable instead of "return"
On Fri, Feb 02, 2001 at 08:09:36AM -0500, Charles Lane wrote: > Peter Scott <[EMAIL PROTECTED]> wrote: > >At 07:12 PM 2/1/01 -0600, David L. Nicol wrote: > >>I recalled hearing about a language (was it java?) where > >>you set the return value of a function (was it VB?) by > >>assigning to the name of the function within the function body, > >>so the last line would be > >> > >> fname=rval; > >> > >>or fname could be used instead of rval all through it. > > > >Ah, an homage to Pascal :-) > > More like Fortran: >REAL FUNCTION FOO(A) >REAL A > C >FOO = 2*A+3 >RETURN >END > ^^^ > note exactly 7 spaces... > > And I think Fortran has a better claim to priority ;) And then there's Parse::RecDescent Abigail
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:
>
>
> Looking over some C code of the form
>
>
>int fname(char *param){
> int rval;
> ...
> return(rval);
>}
>
> I recalled hearing about a language (was it java?) where
> you set the return value of a function (was it VB?) by
> assigning to the name of the function within the function body,
> so the last line would be
>
> fname=rval;
>
> or fname could be used instead of rval all through it.
>
> This obviously allows the compile-time optimization of using the
> lvalue the function will be getting assigned to directly, one fewer
> temporary storage space, as well as saving keystrokes.
>
> Did anyone ever (before) suggest adding this to perl? It would mean
> that
>
> sub subname(proto){
>
> # in here, the bareword "subname" is a magic
> # alias for the lvalue this routine is getting
> # assigned to, if any.
>
> }
>
> We could even define a new line noise variable which could hold the
> results of the last name-of-function subroutine that was not invoked
> as an rvalue (I nominate $__ ); make such an invokation a warning-level
> offense; and make $__ visibility/localization compatible with recursion.
Does that mean there's going to be a @__ as well, for uses in list context?
If so, what happens with:
sub some_sub {
@__ = qw /foo bar baz/;
}
my $fnord = some_sub;
If there isn't going to be a @__ of some sorts, how is the case of the sub
being called in list context going to be handled?
Abigail
Re: assign to magic name-of-function variable instead of "return"
On Mon, Feb 05, 2001 at 11:46:48AM -0500, James Mastros wrote:
>
> In most languages, you do this with
> {
> $ret = 42;
> close FILE;
> unlock $stuff;
> #yadda
> return $ret;
> }
>
> By the time you get to the last line, you've already forgoten WTF you named
> the return variable.
Eh, I don't think that bad memory, or a bad variable naming scheme
justifies this new feature.
If you forget how you name your variables you have much bigger problems
than to have to type 'return'.
Abigail
Re: assign to magic name-of-function variable instead of "return"
On Mon, Feb 05, 2001 at 12:29:34PM -0500, John Porter wrote:
> James Mastros wrote:
> > OTOH, for functions that look more like {startup;
> > compute; teardown}, magic-varable is nice. Think of the functions where you
> > have a varable named $ret or somesuch, and you compute it, have another few
> > lines or few screens of code, and then say "return $ret".
>
> I see this all the time. What would fit the bill is to have something
> like a C block for subs; they get called during the same
> phase as destructors of objects going out of scope.
>
> sub readit {
> open F, "< $f" or die "$f: $!"; # even in the tiniest example
> my $l = ;
> close F;
> $l
> }
>
> becomes
>
> sub readit {
> open F, "< $f" ...
> scalar()
> }
> continue {
> close F;
> }
>
> O.k., the example is a little bogus, what with IO::File etc.
> But for the general case...
We can do something like this already in perl5. There's even a module
on CPAN for it: "End".
use End;
{ my $foo = end {print "Leaving the block\n"};
...
last; # Prints "Leaving the block\n".
...
}
Abigail
Re: assign to magic name-of-function variable instead of "return"
On Tue, Feb 06, 2001 at 08:25:17AM +1100, Damian Conway wrote:
>
>return ( $stuff, $morestuff, $whatever ) always close F;
>
> I *really* like that keyword.
>
> Though I'd prefer to see it as a block suffix:
>
> sub {
> ...
> return $yadda_yadda;
> }
> always { close F }
>
>
> Then you could add it to loops as well, in conjunction with the C:
>
> while (1) {
> ... # add to $text in complex ways
> }
> continue { $text .= "\n"; } # separate with newlines
> always { $trycount++ }# count attempts (including last)
Hmmm. If there's such an "always" block, I'd like to see it on all blocks,
including the continue [1]. But then, it becomes hard to figure out to which
block the always belongs
[1] Only half-joking. I find it irritating I can't chain continue {}
blocks. [2]
[2] I guess this is in the same department as me wanting to 'last' out
of an if () {} else {} blocks, or to redo them.
Abigail
Re: JWZ on s/Java/Perl/
On Fri, Feb 09, 2001 at 12:06:12PM -0500, Ken Fox wrote: > > 2. Work proportional to live data, not total data. This is hard to > believe for a C programmer, but good garbage collectors don't have > to "free" every allocation -- they just have to preserve the live, > or reachable, data. Some researchers have estimated that 90% or > more of all allocated data dies (becomes unreachable) before the > next collection. A ref count system has to work on every object, > but smarter collectors only work on 10% of the objects. So, it's more a data preserver than a garbage collector ;-) Abigail
Re: Auto-install (was autoloaded...)
On Fri, Feb 09, 2001 at 09:22:13PM +, Nicholas Clark wrote: > > Code to do unzip (yes, even including the whole of zlib just like gcc, > xfree86 and several other things I can't remember offhand that irritate > me as I have libz.so) is small enough to go in the perl core if needed. Even after reading this twice, I still get the impression you think both gcc and xfree86 would fit in the perl core snuggly. Oh well, as long as you don't fit emacs in it; there's got to be some limit. Abigail
Re: Auto-install (was autoloaded...)
On Mon, Feb 12, 2001 at 01:28:56PM -0600, Jarkko Hietaniemi wrote: > On Mon, Feb 12, 2001 at 02:19:54PM -0500, [EMAIL PROTECTED] wrote: > > > You have to do that anyway to solve the "what version of glibc are you > > using" problem (and others). > > *minirant* > The world is not not glibc. The world is not Linux. > *end of minirant* > > Either I am being even more grumpier than usual or you people > are making even less sense than usual :-) *microrant* The world is not schwern *end of microrant* Abigail
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 01:30:03PM -0300, Branden wrote: > John Porter wrote: > > James Mastros wrote: > > > I'd think that an extension to delete is in order here. Basicly, delete > > > should DESTROY the arg, change it's value to undef,... > > > > Huh? What delete are you thinking of? This is Perl, not C++. > > > > Agreed, definitely Perl is not C++. > > > > > ...and trigger a GC that will get rid of the arg. > > > > No. Perl decides for itself when to do GC. > > > > Please read the original message I wrote. The reply had only some > off-the-context snippets of the original idea. > > The idea is to *allow* a programmer to explicitly destroy an object, for > better (and sooner) resource disposal. The programmer wouldn't have to do it > (and wouldn't do it most the time), but if he knows he uses many resources > and he would like to be nice, he *could* do it (not meaning he would have to > do it either...). There is no need to add that to Perl, as Perl already has a function for that: C. Naturally, that won't cause DESTROY to be run if there are other references to it, but then, I don't see what an "object destruction" is supposed to do if there are still references to the object left. Nor is this wanted behaviour. All the programmer needs to do for sooner resource disposal it to let his references go out of scope when no longer needed. Abigail
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote: > > Dan Sugalski wrote: > > > Plus there's nothing stopping you from having $obj->DESTROY in your own > > code, though it may be inadvisable. > > It is (mainly) inadvisable because: > 1. GC will call DESTROY when it collects the memory, so 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"? > 2. If I call DESTROY on an object, it would still be a (valid) object after > the call, so that if I call some other method, it will succeed. But that > shouldn't happen, since the object was DESTROYed, right? Eh, you don't understand DESTROY. DESTROY doesn't destroy an object. Perl, the language, does not have the concept of destroying objects. DESTROY is just a call back from perl, the binary, that everyone is done with the object, and it's about to go away. DESTROY might be called around the same time its memory is being reclaimed, but from a language perspective, all this memory dealing is non-existant. DESTROY is a language thing, garbage collection an implementation detail of the run-time, purely necessary because of the limited physical model of the abstract machine Perl is supposed to run on. Their perceived relation is merely a coincidence. Even if you have a bucket load of memory and there was a way of telling Perl not to bother with garbage collection, DESTROY should still be called. Being able to separate DESTROY and garbage collection is a feature. ;-) Abigail
Re: End-of-scope actions: do/eval duality.
On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> Bart Lateur wrote:
> >
> > No, it's a misunderstanding between you and Tony. The "do" your
> > reference is talking about, is of the form
> >
> > do FILE
> >
> > where file is a string containing a filename, while Tony is talking
> > about the
> >
> > do BLOCK
> >
> > form. do FILE behaves just like eval() (except it reads its data from a
> > source file), while do BLOCK doesn't. Neither.
> >
>
> Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> little too much not-orthogonal? Why don't we require `eval { do FILE }' to
> have the behaviour of not dying and setting $@ ?
And that would gains us what exactly?
As the Perl man page says, do FILE is like
scalar eval `cat FILE`;
If you take out the eval, you get:
scalar `cat FILE`;
which is pretty pointless.
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.
Abigail
Re: defined: Short-cutting on || with undef only.
On Thu, Feb 15, 2001 at 10:31:34AM -0300, Branden wrote: > With Perl 6, it will (probably) be possible to have values with boolean > value independent of integer or string values, so that it will be possible > to have a value that when viewed as string or number will be "" or 0, but > will evaluate as true in a condition. You mean the beaten-to-death ??, formely known as |||, operator? It has torn p5p to shreds repeatedly. Abigail
Re: Closures and default lexical-scope for subs
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 to practical to suddenly require more hoops. Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 11:49:44AM -0800, Randal L. Schwartz wrote: > >>>>> "Peter" == Peter Scott <[EMAIL PROTECTED]> writes: > > Peter> Quite. But on a tangent, I see no good reason why this shouldn't be > Peter> given the same interpretation as "my ($a, $b, $c)" on the grounds that > Peter> functions taking list arguments that omit their parentheses swallow up > Peter> the following list. > > *some* functions. localtime doesn't. my is a unary function, prototyped > vaguely as (\$) or (\@) or (\%). If my() would be an unary function, how come that my ($foo, $bar); makes $bar a lexical variable? my just isn't a function. Just like return or while aren't, even when followed by parenthesis. They are language constructs. Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
>
> I agree with this statement. Perhaps someone who was around during the
> initial 'my' discussions can shed some light on why it binds so tightly.
> I have observed you can do something like this:
>
>my $OUTER = '';
>
>if ( $some_value ) {
> # 'my' only on the first one
> (my $inner, $OUTER) = split;
>
> # more code that uses $inner ...
>}
>
>if ( $OUTER ) {
> # $inner not here, but that's fine...
>}
>
> But I have never found a situation where this is so useful to justify
> the other problems it creates. However, there may well be true technical
> reasons why "my $x, $y, $z" does not do what many think it should.
As I wrote elsewhere, other reasons not to change the behaviour of my:
GetOptions (foo => \my $foo,
bar => \my $bar);
tie my $shoe => $tring;
Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 10:44:24AM -0800, Peter Scott wrote: > > Quite. But on a tangent, I see no good reason why this shouldn't be given > the same interpretation as "my ($a, $b, $c)" on the grounds that functions > taking list arguments that omit their parentheses swallow up the following > list. And if the retort is, "my isn't a function," then I would like to > know what it really is and why it's listed in perlfunc along with other > things that aren't functions. my is language construct. Just like if, while and return that can be followed by parenthesis, but aren't functions. > If that's not enough controversy I can also ask about things which are > labelled as both functions and operators :-) Functions and operators are the same. It's just that what is labelled an operator usually takes a fixed number of arguments, often consists of non-alphanumerical characters and unlike what's labelled a function, is often not prefix. But that's only syntactic sugar (and vinegar due to precedence tables). Abigail
Re: End-of-scope actions: do/eval duality.
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote:
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> > > Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> > > little too much not-orthogonal? Why don't we require `eval { do FILE }'
> to
> > > have the behaviour of not dying and setting $@ ?
> >
> > And that would gains us what exactly?
> >
> > As the Perl man page says, do FILE is like
> > scalar eval `cat FILE`;
> > If you take out the eval, you get:
> > scalar `cat FILE`;
> > which is pretty pointless.
> >
> > 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]'.
Ah, you mean the paragraph were Larry suggest renaming homonyms?
Requiring to write "eval {do FILE}" were you first wrote "do FILE;"
seems quite opposite to what he says.
Keeping the semantics but making it "include FILE" seems to be more
in the line what he means.
But then, it might be better to wait till Larry has spoken.
Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 08:19:27PM +, Nicholas Clark wrote:
> On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
> > On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
> > > But I have never found a situation where this is so useful to justify
> > > the other problems it creates. However, there may well be true technical
> > > reasons why "my $x, $y, $z" does not do what many think it should.
> >
> > As I wrote elsewhere, other reasons not to change the behaviour of my:
> >
> > GetOptions (foo => \my $foo,
> > bar => \my $bar);
> >
> > tie my $shoe => $tring;
>
> Hmm. Nathan's example of my is in void context
> Abigail's are not.
>
> As there appears to be a way to tell them apart, is it possible (sane?) to
> make both work? Or at least issue warnings (not mandatory, but defaulting
> to on unless you have some sort of no warnings) for Nathan's case?
> [where () round all three would make it do what he meant]
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
> best way to shoot down my suggestion is an example where existing behaviour
> can't be determined from void/scalar/list context.
Will the above do?
Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 02:03:21PM -0800, Edward Peschko wrote:
> > If I have:
> >
> > (my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
> >
> > then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
> > isn't.
> >
> > Do you really want them to behave differently?
> >
> > > best way to shoot down my suggestion is an example where existing behaviour
> > > can't be determined from void/scalar/list context.
> >
> > Will the above do?
>
> well, I'd say no. How many people are going to run into this and have it not
> do what they expect as opposed to:
>
> my $a, $b, $c;
The point isn't how many are going to run into this.
The point is how to determine when to warn or when not to warn.
It was suggested to DWIM when I use my in void context, and not when
my isn't used in void context. With the above example, such a rule
would mean '$bar1' is my()ed, and '$bar2' isn't. That's IMO, very hard
to explain, very hard to bugtrack and totally unexpected. Even if not
everyone uses it.
> However, I think that:
>
> my $a, $b, $c;
>
> and
>
> my $a, $b, $c = @_;
>
> should work the same and they wouldn't do so if 'void' context was the only
> criteria used.
Both of the above my()s are in void context.
Also, if I have:
@a = (1 .. 10);
$a, $b, $c = @_;
$c becomes 10. Should $c become 3 when my is placed before $a?
Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote: > > > Also, if I have: > > > > @a = (1 .. 10); > > $a, $b, $c = @_; > > How about 'an implicit parens around a set of statements separated by commas > in any context'? This is consistent > > $a, $b, $c = $d, $e, $f; # ($a, $b, $c) = ($d, $e, $f); Do you mean: (($a, $b), $c) = (($d, $e), $f); perhaps? > And if you say something like: > > $a, $b, $c == 10, $d == 11 > > you need to disambiguate the sub-statements by saying > > $a, $b, ($c ==10), ($d == 11) So, the cost of leaving off parens at some places, is to add them elsewhere? What's the point? In the long run, you aren't gaining anything, all you are doing is messing up the precedence table. It's already complicated enough, why have a different precendence table in perl6? Fine, you might not need the parens for my(), you suddenly need them where you don't need them in perl5. > > my $a = # DWIM > > my $a, $b, $c. > > As for your examples: > > GetOptions (foo => \(my $foo), bar => \(my $bar)) > > tie (my $shoe) => $string; Not enough arguments for tie... This trap is documented. > both of these look easier to follow to me, at least. You're kidding, right? If I wanted LISP, I know where to find it. > > $c becomes 10. Should $c become 3 when my is placed before $a? > > No, I think in both cases, they should produce '3'. Ah, more pointless changes with perl5. I think I've seen enough of perl6 by now. I'll treasure my copy of perl5 till the end of times. Abigail
Re: Perl 6 Microgrants. Now accepting proposals.
On Thu, Mar 22, 2007 at 09:53:39PM -0400, Nathan Gray wrote: > On Thu, Mar 22, 2007 at 01:24:58PM +, Tim Bunce wrote: > > Here's a related idea: write a tool that reads BNF grammar, such as > > http://java.sun.com/docs/books/jls/third_edition/html/syntax.html > > http://java.sun.com/docs/books/jls/third_edition/html/grammars.html > > and writes a parser in Perl 6 for that grammar. > > Writing a Perl 6 grammar to parse BNF should not be too hard. Writing a 5.10 regular expression to parse BNF shouldn't be too hard either. Abigail pgp0QsSS8lU00.pgp Description: PGP signature
Re: %_ - is it available for use?
On Sat, Aug 02, 2003 at 04:33:19PM -0700, Michael G Schwern wrote: > > Damian Conway <[EMAIL PROTECTED]> writes: > > >Hence, making C<%_> mean something different in core Perl 5 might possibly be > > >"forwards incompatible". > > Representing the Backwards Compatiblity Police, I've had co-workers use > %_ as the globalist of all global hashes. %_ transends all packages and > scopes and Perl does not localize it, touch it or use it as it does @_ and > $_. In the particular case I'm thinking of, it was used to hold global > arguments for function calls in a template system. Rather insane, really. > Lots of better ways to do it and clearly making use of an undefined > language feature. > > I'm not making an argument against %_, just noting that *_ is used > opportunisticly and you will break a few programs. I am fond of doing local %_ = @_; as one of the first statements of a subroutine. That, or my %args = @_; I like the latter because it uses a lexical variable, but I like the former because %_ fits with @_ and $_. Abigail
Re: rethinking printf
On Wed, Mar 06, 2002 at 11:15:30PM -0500, Uri Guttman wrote:
> >>>>> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:
>
> BL> On Wed, 6 Mar 2002 17:57:07 -0500, Uri Guttman wrote:
> >> how often will you need to interpolate a hash?
>
> BL> A whole hash: quite rarely. A hash item: a LOT. Don't forget that
> BL> $foo{BAR} will now become %foo{BAR}
>
> good point. $() can still wrap that but then there has to be a balance
> between printf strings and double quoters. how about this wacky idea:
>
> make a new type of string where %foo{bar} is not interpolated by
> default. maybe something in the q/qq family could be added like qn for
> no hash interpolation. you can use $() to still force it if you need to
> in printf formats.
>
> just trying out various ideas,
I'd think it would be much better that '%' followed by a word *not*
followed by a { isn't interpolated. Granted, you cannot do interpolation
of hashes (well, one could always write "@{[%hash]}", just like in perl5,
and there's little change of clashing with printf formats. There's only
a clash if a format specifier is followed by a brace.
But the way perl6 is going, I doubt we'll see this kind of DWIM; perl6
is going more in the way of a bondage and discipline language.
Abigail
Re: Fisher-Yates shuffle
On Fri, Apr 12, 2002 at 04:00:37PM +0100, Piers Cawley wrote:
>
> [EMAIL PROTECTED] writes:
> > As for "cleanness", this is my interpretation of how perl6 is going
> > to work:
> >
> > %foo = ();
> > if %foo {"key"} {print "Hello 1"}
> >
> > %foo = ();
> > if %foo{"key"} {print "Hello 2"}
> >
> > %foo = ();
> > if %foo{"key"}{print "Hello 3"}
> >
> > Case 1 will print "Hello 1"; this is a block after the if statement.
>
> No, it will be a syntax error. The first closing brace does not end
> the statement, probably something like "Block seen when keyword
> expected".
Now I am confused. In perl6, we can leave off the the parenthesis
around a condition, and I hope that it isn't required to have
an 'elsif' or 'else' block.
Why isn't
if %foo {"key"} {print "Hello 1"}
equivalent with the perl5 syntax:
if (%foo) {"key"} {print "Hello 1"}
Which keyword is it expecting?
> > Case 2 will not print anything. The print is in the 'then' part
> >of the if.
>
> Correct.
>
> > Case 3 will be a syntax error - an if statement with a condition,
> >but not block.
>
> It won't be a syntax error *yet*. If there's a block immediately
> following then that will be treated as the 'then' block. If it's the
> end of file, or a nonblock, then it'll be a syntax error.
Did the code show anything following it? No? Well, then assume
it isn't there. ;-)
Next time I'll show this to someone, I'll add a semicolon.
Abigail
Re: Fisher-Yates shuffle
On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
> [EMAIL PROTECTED] writes:
> >
> > Why isn't
> >
> > if %foo {"key"} {print "Hello 1"}
> >
> > equivalent with the perl5 syntax:
> >
> > if (%foo) {"key"} {print "Hello 1"}
> >
> > Which keyword is it expecting?
>
> Keyword /els(e|if)/, or end of line, or semicolon. Sorry badly phrased
> on my part. The closing brace of {"key"} only ends the statement if it
> is followed by /\s*$/, or a semicolon.
You've got to be kidding. That makes the whitespace rules even more
insane; your program can behave quite differently wether there's a space,
a newline, or nothing between two tokens. Wonderful! People who tend
to use -e all the time (like me) will love it. (Not!) Pasting code into
IRC will be so much more fun.
I'll treasure my perl5 sources.
Abigail
Re: Fisher-Yates shuffle
On Fri, Apr 12, 2002 at 02:14:36PM -0700, Erik Steven Harrison wrote:
>
> --
>
> On Fri, 12 Apr 2002 18:27:11
> abigail wrote:
> >On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
> >> [EMAIL PROTECTED] writes:
> >> >
> >> > Why isn't
> >> >
> >> > if %foo {"key"} {print "Hello 1"}
> >> >
> >> > equivalent with the perl5 syntax:
> >> >
> >> > if (%foo) {"key"} {print "Hello 1"}
> >> >
> >> > Which keyword is it expecting?
> >>
> >> Keyword /els(e|if)/, or end of line, or semicolon. Sorry badly phrased
> >> on my part. The closing brace of {"key"} only ends the statement if it
>
>
> As i understand it (Tell me if I'm wrong) This
>
> %hash {key};
>
> will not work, because space between the hashname and the brace was no longer
>allowed. This allows for
"Will not work" is not correct. "%hash {key}" is parsed as an expression
followed by a block. Whether that will work depends on the context.
'if' for instance is followed by an expression and a block..., so
if %hash {key}
*will* work, except it does something totally different than one might
expect.
>
> if %hash{key} { ... }
>
> and also
>
> if $scalar { ... }.
>
> The only other white space rule is that white space after the closing brace of a
>closure, when that closure is the last argument of a user defined sub get's treated
>as a semicolon if there is nothing else on that line. This allows custom iterators to
>parse (or appear to parse) like builtins.
>
> myforeach @arry, %hash, $scalar {
>...
> }
> #No semicolon required!
>
> What problems does this seem to cause - I don't see anything wrong. I don't see how
>(except in the case of closure as last argument) how it matters one way or another
>what kind white space appears between tokens.
>
> What am I missing?
What you are missing is the new white space rule:
\s+{ }
shall be always be a block. Hence the difference between
"%hash {foo}" and "%hash{foo}".
Abigail
