Re: pascal-like with was Re: Default filehandles(was Re: command line option: $|++)
This seems good...the HOF stuff seems to have pretty well accepted, and
the thumbtack notation with it.
Dave
On Thu, 17 Aug 2000, Clayton Scott wrote:
On Wed, 16 Aug 2000, David L. Nicol wrote:
%record = loadrecord($studentID);
with %record {
print SPAM;
Dear $Name:
Your tuition is now due. Please send in a payment
of at least $Minumum.
SPAM
# anyone for having a python-like floating left edge for
# retaining indentation of hereis strings?
};
This seems less of a leap of logic/faith:
%record = loadrecord($studentID);
with %record {
print SPAM;
Dear ^name:
Your tuition is now due. Please send in a payment of at least
^minumum.
SPAM
};
Re: pascal-like with was Re: Default filehandles(was Re: command line option: $|++)
Dave Storrs wrote:
On 17 Aug 2000, Johan Vromans wrote:
Dave Storrs [EMAIL PROTECTED] writes:
2) "express" should guarantee that, before it creates a variable
names $FOO, it first calls "local" on any existing $FOO
Why, if the variable is lexical (see 3)?
D'oh. s{2) .+^}{}
Mismatch between brain and fingers there somewhere, thanks for
pointing it out.
Huh? They need to be "globals", because the "with" mechanism
is going to have to be able to write them into a symbol table.
You can't do this with lexicals. (Well, maybe that'll be different
in perl6?)
--
John Porter
Re: pascal-like with was Re: Default filehandles(was Re: command line option: $|++)
This seems less of a leap of logic/faith:
%record = loadrecord($studentID);
with %record {
print SPAM;
Dear ^name:
Your tuition is now due. Please send in a payment of at least
^minumum.
SPAM
};
"I do not thin' that means wha' you thin' it means".
This:
print SPAM;
Dear ^name:
Your tuition is now due. Please send in a payment of at least
^minumum.
SPAM
already means:
print sub {
return SPAM;
Dear $_[0]
Your tuition is now due. Please send in a payment of at least
$_[1].
SPAM
}
So Cwith is going to have to do some pretty freaky magic to work out
it should call that sub as part of the Cprint. And call it with a
specifically ordered argument list.
However, your suggestion *did* spark an excellent idea for me to do,
with named placeholders and named subroutine parameters. Many thanks!
Damian
Re: pascal-like with was Re: Default filehandles(was Re: command line option: $|++)
Damian Conway wrote: So Cwith is going to have to do some pretty freaky magic to work out it should call that sub as part of the Cprint. And call it with a specifically ordered argument list. Yes, I never said it would work, just that it looked nicer :) However, your suggestion *did* spark an excellent idea for me to do, with named placeholders and named subroutine parameters. Many thanks! We're still not even. I got quite a few ideas from your book. Clayton -- Clayton Scott
Re: Default filehandles(was Re: command line option: $|++)
I'm not sure if you are disagreeing with me or not. The context was the statment that $STDOUT is the _default_ filehandle. I was pointing out that by _overriding_ the instantaneous meaning of $STDOUT to the default fail handle, one would lose the immediate access to the previous value. I.e. $STDOUT should always mean one and only one file at a time. Unless one wants to have a $DEFAULT filehandle and get rid of single arg select. chaim "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: JSD On Tue, Aug 15, 2000 at 06:53:30PM -0400, Chaim Frenkel wrote: What if you want to print to a default file handle and also to STDOUT? select(OTHERFH); print "This goest to OTHERFH\n"; print STDOOUT "This went to STDOUT\n"; JSD print $_ "Here I come to save the day!\n" for ($PERL::STDOUT, $myfh); JSD And again, if you want to print different stuff to different JSD filehandles, you know how to use the JSDprint FILEHANDLE LIST; JSD version of print. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Default filehandles(was Re: command line option: $|++)
Chaim Frenkel wrote: Unless one wants to have a $DEFAULT filehandle and get rid of single arg select. Great minds think alike. :-) I'm in the process of codifying an RFC that will be titled something like: "Replace default filehandle / select with $OUTPUT fileobject" (chose $OUTPUT b/c of $OUTPUT_* variables) Everyone: Let's DROP IT. When the RFC comes out (today), let's pick this back up on -io. Thanks. -Nate P.S. If you're not on -io, this implicitly means you DON'T CARE and are willing to accept whatever we come up with. So, everyone that's interested please get on -io. Thanks again.
Re: Default filehandles(was Re: command line option: $|++)
Chaim Frenkel wrote: NW P.S. If you're not on -io, this implicitly means you DON'T CARE and are NW willing to accept whatever we come up with. So, everyone that's NW interested please get on -io. Thanks again. That's a bit strong. All we are doing is filtering the garbage for Larry. Larry may well be reading for flavour. Obviously, this certainly wasn't meant to apply to Larry. And you forgot Rule #2. Larry can always change his mind. Sure. My only point was that we've retraced the exact same discussion about default filehandles twice now, once on -io and once on -language, with the exact same conclusion. This is just plain a waste of time and emails. It's not anybody's fault, and I'm not mad. Just everyone, PLEASE try to get on lists that you care about. It saves time and cuts down on the extremely high bandwidth that is -language. Thanks, Nate
Re: command line option: $|++
Sounds like a good idea. I propose a commandline arg that gives info about modules in @INC also. I emailed this to the list earlier but it never seemed to make it. Something like perl -M 'Digest' might return: /usr/local/lib/perl5/site_perl/: -r--r--r-- 1 root other 4733 Aug 5 1999 Digest.pm From: Uri Guttman [EMAIL PROTECTED] Reply-To: Uri Guttman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: command line option: $|++ Date: Tue, 15 Aug 2000 00:08:24 -0400 i just found an interseting little oddity i want fixed. i (like many of you) run one liners for testing snippets of code. i typically use a -p or -n loop and type in test data. i get tired of retyping in all the data each time when i want to edit the previous line only a little bit. i tried using ssfe (split screen front end, comes with sirc char client) and i saw no output due to pipe buffering. so i had to put a $|++ in the one liner to make it work. perl6 should have a command line option to enable $| for STDOUT. i haven't see any threads about perl's command line options. like the special variables, i think it could use a good editing and overhaul. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: command line option: $|++
Today around 12:08am, Uri Guttman hammered out this masterpiece:
: i just found an interseting little oddity i want fixed. i (like many of
: you) run one liners for testing snippets of code. i typically use a -p
: or -n loop and type in test data. i get tired of retyping in all the
: data each time when i want to edit the previous line only a little
: bit. i tried using ssfe (split screen front end, comes with sirc char
: client) and i saw no output due to pipe buffering. so i had to put a
: $|++ in the one liner to make it work. perl6 should have a command line
: option to enable $| for STDOUT.
cat /etc/passwd | perl -nfe 'print((split/:/)[0])'
-f is just like $|=1 or, for example, $fh-autoflush(1);
This, by the way (even as a test) was agravating to me because in order to
get decent output I really had to do this:
cat /etc/passwd | perl -nfe '$\="\n";print((split/:/)[0])'
or
cat /etc/passwd | perl -nfe 'print((split/:/)[0]."\n")'
So perhaps we should allow all the 'special' variables, namely the
scalars, to be assigned to on the command line via thier English
representations. Observe:
perl -OUTPUT_AUTOFLUSH=1 -OUTPUT_RECORD_SEPARATOR="\n" -ne 'print((split/:/)[0])'
Or something to that effect. However, I suppose the same could be done
with thier punctuation defaults:
cat /etc/passwd | perl '-$|=1' '-$\="\n"' -ne 'print((split/:/)[0])'
This might be nice if you can set your environment vars to have a few
defaults such as autoflush(1).
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: command line option: $|++
On Tue, Aug 15, 2000 at 09:14:20AM -0400, Casey R. Tweten wrote:
This, by the way (even as a test) was agravating to me because in order to
get decent output I really had to do this:
cat /etc/passwd | perl -nfe '$\="\n";print((split/:/)[0])'
cat /etc/passwd | perl -lnfe 'print((split/:/)[0])'
So perhaps we should allow all the 'special' variables, namely the
scalars, to be assigned to on the command line via thier English
representations. Observe:
perl -OUTPUT_AUTOFLUSH=1 -OUTPUT_RECORD_SEPARATOR="\n" -ne 'print((split/:/)[0])'
If you're going to be that verbose, might as well put that in the
program itself.
perl -lne 'BEGIN { $|=1; $/="\n"; } print ((split/:/)[0])'
Or something to that effect. However, I suppose the same could be done
with thier punctuation defaults:
cat /etc/passwd | perl '-$|=1' '-$\="\n"' -ne 'print((split/:/)[0])'
Ick.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: command line option: $|++
Ed Mills wrote: Sounds like a good idea. I propose a commandline arg that gives info about modules in @INC also. I emailed this to the list earlier but it never seemed to make it. Something like perl -M 'Digest' might return: /usr/local/lib/perl5/site_perl/: -r--r--r-- 1 root other 4733 Aug 5 1999 Digest.pm It hasn't been forgotten! I'm still working on a module registry, which should address this. Should be out by the end of the week. -Nate
Re: command line option: $|++
Today around 11:01am, Jonathan Scott Duff hammered out this masterpiece:
: On Tue, Aug 15, 2000 at 09:14:20AM -0400, Casey R. Tweten wrote:
: This, by the way (even as a test) was agravating to me because in order to
: get decent output I really had to do this:
:
: cat /etc/passwd | perl -nfe '$\="\n";print((split/:/)[0])'
:
: cat /etc/passwd | perl -lnfe 'print((split/:/)[0])'
Yes, I know.
: So perhaps we should allow all the 'special' variables, namely the
: scalars, to be assigned to on the command line via thier English
: representations. Observe:
:
: perl -OUTPUT_AUTOFLUSH=1 -OUTPUT_RECORD_SEPARATOR="\n" -ne 'print((split/:/)[0])'
:
: If you're going to be that verbose, might as well put that in the
: program itself.
:
: perl -lne 'BEGIN { $|=1; $/="\n"; } print ((split/:/)[0])'
Frankly, they're both ugly. I personally like the *idea*, I'm not
advocating my solution. It would be wonderful if we could assign values
to Perl's special variables when we're doing a one line quick
hack. Often, I will modify default values in programs in order to be
more lazy. That isn't easily available for a command line hack ( and 80 -
120 characters on the line ( give or take ) ). Why not make it more
available?
And, sure, perhaps the idea bytes, so scratch it. However, I love the
idea of `-f` or something like it, to turn off output buffering.
: Or something to that effect. However, I suppose the same could be done
: with thier punctuation defaults:
:
: cat /etc/passwd | perl '-$|=1' '-$\="\n"' -ne 'print((split/:/)[0])'
:
: Ick.
Just an alternative, I don't like it either, frankly.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: command line option: $|++
On Tue, Aug 15, 2000 at 10:03:55AM -0700, Nathan Wiger wrote: Jonathan Scott Duff wrote: Well, now it's my turn to suggest something ;- How about we give perl the ability to look for a .perlrc file? (Yes, I know the reasons against, but everything is up for grabs now right? :-) If we do this, it should be off by default. csk/ksh make you turn it off, which is the *WRONG* approach. Instead, add a boolean switch that says "reading ~/.perlrc is ok for this script". Maybe -r could be used for that. Scott, I'd suggest codifying ~/.perlrc in an RFC, real quick, before the heated arguments begin. :-) I'll RFC it later today probably. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: command line option: $|++
At 12:31 PM 8/15/00 -0400, Casey R. Tweten wrote: Frankly, they're both ugly. I personally like the *idea*, I'm not advocating my solution. It would be wonderful if we could assign values to Perl's special variables when we're doing a one line quick hack. With a bit of luck, the special variables are going away. $| will be replaced by some line discipline method or whatever it's called. Quite what impact this has for one-liners has yet to be explored, but I think it's going to require a lot more thought. Can someone knowledgeable on this issue speak to it? Will $| $/ $\ et al be retired, or be valid for some default filehandle? Will there still be default filehandles? Will there be a way of altering the line discipline characteristics or whatever they're called globally? If so, how? Any plans as yet for changing the -0 and -l command line flags? -- Peter Scott Pacific Systems Design Technologies
Default filehandles(was Re: command line option: $|++)
Peter Scott wrote: I don't want to be in the -io discussion; I just want to know the conclusions that might affect -language. It seems silly to discuss command-line options for setting $| here if there isn't going to be a $|. Ok, read this thread (4 messages long): http://www.mail-archive.com/perl6-language-io@perl.org/msg00094.html This is a succinct summary of the basic conclusions thus far: 1. a default filehandle IS needed sometimes, but only for stuff like print 2. $|, $\, $/, etc will probably go away entirely in favor of object methods such as $handle-autoflush That's the current thinking. As always, this is subject to change. However, most everyone seems to agree that "having global $| vars that aren't really global but actually depend on what the currently selected filehandle is which depends on what select() was called on" is bad. So, setting stuff like autoflush will probably be object methods only. Setting stuff like the default for print will probably still be via the default filehandle. -Nate
Re: Default filehandles(was Re: command line option: $|++)
On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote: This is a succinct summary of the basic conclusions thus far: 1. a default filehandle IS needed sometimes, but only for stuff like print Well, I think that Cprint should always print to $PERL::STDOUT (or whatever we call it) always; same with Cprintf(). I'd hardly call that "default" though. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Default filehandles(was Re: command line option: $|++)
Jonathan Scott Duff wrote: On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote: This is a succinct summary of the basic conclusions thus far: 1. a default filehandle IS needed sometimes, but only for stuff like print Well, I think that Cprint should always print to $PERL::STDOUT (or whatever we call it) always; same with Cprintf(). I'd hardly call that "default" though. Read the link I sent out. There's a reason this doesn't work. -Nate
Re: Default filehandles(was Re: command line option: $|++)
"JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: JSD On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote: This is a succinct summary of the basic conclusions thus far: 1. a default filehandle IS needed sometimes, but only for stuff like print JSD Well, I think that Cprint should always print to $PERL::STDOUT (or JSD whatever we call it) always; same with Cprintf(). I'd hardly call that JSD "default" though. Err, no. What if you want to print to a default file handle and also to STDOUT? select(OTHERFH); print "This goest to OTHERFH\n"; print STDOOUT "This went to STDOUT\n"; STDOUT is _not_ the default filehandle. It is the currently selected filehandle when perl starts. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Default filehandles(was Re: command line option: $|++)
"NW" == Nathan Wiger [EMAIL PROTECTED] writes: NW2. $|, $\, $/, etc will probably go away entirely in NW favor of object methods such as $handle-autoflush It think they will still be needed as lexical variables used as an initializer for the corresponding per-filehandle value. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Default filehandles(was Re: command line option: $|++)
At 12:57 PM 8/15/00 -0700, Nathan Wiger wrote: This is a succinct summary of the basic conclusions thus far: 1. a default filehandle IS needed sometimes, but only for stuff like print 2. $|, $\, $/, etc will probably go away entirely in favor of object methods such as $handle-autoflush That's the current thinking. As always, this is subject to change. However, most everyone seems to agree that "having global $| vars that aren't really global but actually depend on what the currently selected filehandle is which depends on what select() was called on" is bad. So, setting stuff like autoflush will probably be object methods only. Setting stuff like the default for print will probably still be via the default filehandle. Okay, so I guess it makes sense to define some command-line options that change the line characteristics for STDOUT and STDIN, which is what it boils down to. While you're at it, mebbe you could come up with something better than @F for -a :-) -- Peter Scott Pacific Systems Design Technologies
Re: Default filehandles(was Re: command line option: $|++)
On Tue, Aug 15, 2000 at 06:53:30PM -0400, Chaim Frenkel wrote: What if you want to print to a default file handle and also to STDOUT? select(OTHERFH); print "This goest to OTHERFH\n"; print STDOOUT "This went to STDOUT\n"; print $_ "Here I come to save the day!\n" for ($PERL::STDOUT, $myfh); And again, if you want to print different stuff to different filehandles, you know how to use the print FILEHANDLE LIST; version of print. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: command line option: $|++
Peter Scott wrote: Can someone knowledgeable on this issue speak to it? Will $| $/ $\ et al be retired, or be valid for some default filehandle? Will there still be default filehandles? There's been a big debate on the -io list about this. No clear decisions yet, but looks like the answer to "default filehandles?" will probably be "yes". Anyone interested in this issue I urge you to take it to -io for additional discussion. Thanks, Nate
Re: command line option: $|++
Jonathan Scott Duff wrote: Well, now it's my turn to suggest something ;- How about we give perl the ability to look for a .perlrc file? (Yes, I know the reasons against, but everything is up for grabs now right? :-) If we do this, it should be off by default. csk/ksh make you turn it off, which is the *WRONG* approach. Instead, add a boolean switch that says "reading ~/.perlrc is ok for this script". Maybe -r could be used for that. Scott, I'd suggest codifying ~/.perlrc in an RFC, real quick, before the heated arguments begin. :-) -Nate
