Re: errors and their keywords and where catch can return toandst uff like that
On Mon, Aug 14, 2000 at 10:15:21PM -0700, Peter Scott wrote:
At 08:56 PM 8/14/00 -0600, Tony Olekshy wrote:
consider this:
try { may_throw_1; }
catch { may_throw_2; }
catch { may_throw_3; }
finally { may_throw_4; }
That's either a syntax error or a no-op. More likely the latter. If you
have multiple catch blocks which could catch the same exception, only the
first one should execute.
Yes.
Graham.
Re: RFC 63 (v3) Exception handling syntax
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL RFC 80 proposes standard exception classes and methods for core exceptions.
PRL This RFC doesn't need to repeat those, but it can expound upon the
PRL semantics that exception classes ought to have. Assume wlog that they
PRL all inherit from a base class, CException. Some people think that
PRL exceptions should not be rethrown implicitly. We can provide a boolean flag
PRL in the class or even the exception object itself to be checked for this:
PRL sub Exception::IO::implicit_rethrow { 0 }# One class
PRL sub Exception::implicit_rethrow { 0 }# All classes
PRL throw Exception::Socket(implicit_rethrow = 0); # Just this exception
PRL [Note: it had been proposed that this functionality would be provided by a
PRL method Cuncaught_handler which would be called if an exception wasn't
PRL caught.
PRL But if that routine decided to rethrow the exception, the Ccontinue block
PRL would not get called at the right time.]
Please include the comments about global variables and action at a distance.
PRL =head2 Exception classes - ignoring
PRL Note that we could also make it possible to selectively or globally ignore
PRL exceptions, so that perl continues executing the line after the Cthrow
PRL statement. Just import a Cignore function that takes a class name:
PRL ignore Exception::IO; # Ignore all I/O exceptions
PRL ignore Exception; # Ignore all exceptions
PRL and when perl sees the Cthrow, it just does nothing. (Or do it by
PRL overriding a base class method as for Cimplicit_rethrow if you don't want
PRL to put another function in the namespace.) Since Cthrow and Cdie
PRL should be essentially identical, this would allow any kind of exception to
PRL be ignored, not just the ones that were Cthrown. This is not necessarily
PRL a good thing, of course.
Oh, no! Are you really suggesting that after
open (FOO, "nonesuch") or throw "file not found"
The next statement continues??
How in $DIETY's name do you expect to protect code?
PRL =head2 $SIG{__DIE__}
PRL $SIG{__DIE__} needs to be triggered only as a Ilast resort
PRL instead of firing immediately, since it messes with the mind of this and
PRL every other decent exception handling mechanism. Perhaps it should be axed
PRL altogether. Please.
$SIG{DIE} should die. Action at a distance. Global. Can't know what
other threads or modules want done here.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Unify the Exception and Error Message RFCs?
On Sun, Aug 13, 2000 at 07:35:06PM -0700, Peter Scott wrote: At 03:30 PM 8/13/00 -0500, David L. Nicol wrote: Whose RFC deals with this? 63, 70, 80, 88 and 96. There would appear to be a groundswell of interest :-) Well yes, but they represent three authors with (as best I can tell) pretty similar views of what needs done. With advance apologies for the over-simplification, these RFCs very briefly summarize to: 63 - Error handling syntax to be based on fatal.pm, a Java-ish try/catch (Peter Scott). 70 - Allow full error handling via exception-based errors based on expansion of and addition to fatal.pm (Bennett Todd) 80 - Builtins should permit try/throw/catch as per Java/fatalpm style (Peter Scott). 88 - Propopses error handling via mechanisms of try, throw, except, etc. (Tony Olekshy). 96 - Proposes establishing a base class for exception objects, which could work with either of the two groups above and might subsume RFC3 as well (Tony Olekshy) I'd like to see these throw into a post (possibly including RFC3 (Brust) as well), and pulled out a single proposal with o a unified proposal for a general try/throw/catch error handling mechanism for perl o a recommended object-based implementation of it o recommended areas where it should be applied in the perl core o a mechanism allowing programmers to take over error message production for the above group of items and a separate proposal for o a mechanism allowing programmers to take over error message production for other types I'm assuming that not all errors would move to the object or try/catch sort of arrangement; there are lots of times that return values or unrecoverable errors are all you really need. For the last, one should use `eval' if you really need to catch them; but an ability to override the error message may well be sufficient in most cases. And should the first proposal fail, the second becomes even more critical. IMHO trading six RFCs for two will greatly improve the chance of passing.
Re: Exceptions and Objects
Jonathan Scott Duff [EMAIL PROTECTED] writes: On Sun, Aug 13, 2000 at 10:51:24PM -0700, Peter Scott wrote: Could be. I'd be interested in seeing non-OOP proposals that do what I want exceptions to do, I have a hard time imagining one. Well, what is it that you want exceptions to do? What does it mean for an exception to have semantics? When an exception is thrown does something special happen whether it's caught or not? Yes. In my proposal, if it's caught, the catcher examines the exception object. If it isn't caught, the program dies with the message attribute as text. This doesn't show that the exception object itself has any semantics. If the catcher examines, the object is being passive. Does the object *do* anything? I want it to be able to. Depends on how you write it... -- Piers
Re: RFC 14 (v3) Modify open() to support FileObjects and
On Mon, Aug 14, 2000 at 03:01:54PM -0700, Nathan Wiger wrote:
or less verbose,
$fh = open "http://my.homepage.com";
This is still up in the air. I think this will probably end up doing a
GET via the http handler on the webpage specified. That seems the most
natural, since you'd probably want these to work the same:
open http "http://www.yahoo.com"; # GET
open "http://www.yahoo.com"; # GET also
Random thoughts:
open "http://www.perl.com";
open "http://www.perl.com?foo=barbaz=blat";
open "http://www.perl.com", %args;
open "http://www.perl.com", { mode = 'POST' }, %args;
Hmm. I think that "modes" should be made explicit rather than relying
on special characters fore or aft of the "filename". Especially since
the individual handlers get to decide how they want to treat that
filename.
I'd say any "filename" that starts with the usual open-special
characters should take the rest of the string as a literal filename on
the local system.
Which makes it consistent with these, which you'd assume would work the
same:
open "/var/log/mylog";
open "file:///var/log/mylog";
open "file:///var/log/mylog", { mode = 'APPEND' };
Here's a translation of the last http and the above file opens:
http-open("http://www.perl.com", { mode = 'POST' }, %args);
file-open("file:///var/log/mylog", { mode = 'APPEND' });
What do you think?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 100 (v1) Embed full URI support into Perl
Sam Tregar wrote: How is this better than File::Spec's approach? File::Spec has the idea and representation dead on. However, the interface is a pain; to write portable scripts you have to go through some contortions. With URI support, you still have to contort a little, but not as much. Here's some better examples from an email I sent earlier: $fo = open "file://c/docs/personal"; # Unix = /docs/personal# here, 'c' becomes '/' # Mac = :docs:personal# here, 'c' becomes ':' # Win = c:\docs\personal Something like File::Spec can be used to perform the magic internally, but you get the benefit of not having to call catfile explicitly. Perl sees a URI and does its thing. Plus, URIs are familiar - most everyone (even those unfamiliar with Perl) understands what the URI in the open statement does. Although the examples are terrible at showing it (sorry), full URI support means more that just writing portable filenames. It means having Perl understand http://, ftp://, etc, etc, so that it can do something "really cool" with it. The upcoming v4 of RFC 14 will show how this is an advantage. -Nate
Re: RFC 100 (v1) Embed full URI support into Perl
On Tue, 15 Aug 2000, Nathan Wiger wrote: With URI support, you still have to contort a little, but not as much. Here's some better examples from an email I sent earlier: $fo = open "file://c/docs/personal"; # Unix = /docs/personal# here, 'c' becomes '/' # Mac = :docs:personal# here, 'c' becomes ':' # Win = c:\docs\personal Really? I would have expected that to be "/c/docs/personal" under UNIX. Strangely enough Netscape on my Linux box thought I wanted to contact a server called "c". Lynx thought I wanted to contact an FTP server. So, what's so portable about file:// URLs again? How do they magically know that //c/ means / on UNIX? What do they do with //z/? Although the examples are terrible at showing it (sorry), full URI support means more that just writing portable filenames. It means having Perl understand http://, ftp://, etc, etc, so that it can do something "really cool" with it. The upcoming v4 of RFC 14 will show how this is an advantage. Have you ever used LWP? It's already "really cool". Should we package it with Perl6? Sure! Should we try to cram its many protocols into open? I'm not so sure. -sam
Re: RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default
On Tue, Aug 15, 2000 at 08:02:46PM -, Perl6 RFC Librarian wrote: =head1 TITLE Yet another lexical variable proposal: lexical variables made default without requiring strict 'vars' Am I correct that the only significant difference between this and RFC 6 is that RFC says we should have to Cuse strict 'vars'; to get lexicals by default and this one says we shouldn't have to? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default
without requiring strict 'vars'
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Yet another lexical variable proposal: lexical variables made default
without requiring strict 'vars'
=head1 VERSION
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Date: 15 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 106
=head1 ABSTRACT
Perl was originally designed around dynamically-scoped variables.
Many users would like to see this design flaw fixed, but are disagreed
about how to go about it. This proposal suggests making undeclared
variables be lexical by default in Perl6 and deals with the possible
ambiguities this could bring about. An optional suggestion is made as
to how one might go even further and eliminate dynamic variables
entirely from the language.
=head1 DESCRIPTION
Lexically-scoped variables are easy to use and intuitive, in that any
lexical variable refers to a variable declared within the current
scope or the enclosing scope. The variable can be located by
lexically scanning the source code. Dynamic variables, on the other
hand, refer to a variable from within the current scope or from within
the current subroutines _caller_, which could be anywhere! It is
impossible to tell exactly what else might be happening to a dynamic
variable, resulting in various action at a distance problems, variable
suicide problems, and other difficulties.
Under this proposal, lexical variables are considered to be the norm
for Perl6. Any undeclared variable is considered to be a lexical
variable.
=head2 Scopes
An undeclared variable is lexical and visible only within the scope
where it is first used and any scopes contained within that one. The
notion of "scope" is the same as Perl has had almost since the
beginning: a block (including a subroutine block) begins a new scope;
a file is also a scope.
Thus, in the following code segment,
$x = 15;
$y = $x;
while ($y) {
$z = $y;
...
$x += $z;
}
$x and $y are lexicals contained in the outermost scope (probably a
file), while $z is a lexical available only in the while loop. When
used within the while loop, $x and $y refer to the same scalars
referred to outside of the while loop.
=head2 Use of Cmy
In all cases, the Cmy operator behaves as it does in Perl5, allowing
local variables that will not interfere with other variables, etc.
=head2 Dynamic Assignment
Dynamic assignment is the technical term given to the action performed
by Clocal in Perl5 and earlier versions. The value of a variable is
saved upon execution of the operator and restored when the current
scope ends.
There is no actual reason why dynamic assignment needs to be limited
to dynamic variables. This RFC strongly suggests that dynamic
assignment be enabled for lexical variables, as well. Programming
with all lexicals and occasional use of dynamic assignment can cover
many of the cases where dynamically-scoped variables are useful.
Note that Clocal will probably be renamed in Perl6.
=head2 Ambiguity
Several people have raised issues about possible ambiguities with this
idea, but they have all been instances of the same problem: the case
where an undeclared variable is used first within a block, then within
that block's containing scope. For example,
$cond = ...;
if ($cond) {
...
$color = "blue";
...
}
print "The color is $color\n";
The programmer expects the value of $color to be "blue" for the print
statement, but in fact $color is a brand-new, undefined, lexical
variable.
Translating this block from Perl5 to get the same behavior in Perl6 if
this RFC is adopted is straightforward and discussed in the
IMPLEMENTATION section.
There are two options for dealing with this construct in new Perl6
code:
=over 4
=item 1
Dubbed the "conservative" approach by Mark-Jason Dominus, this option
requires that the programmer disambiguate the situation by declaring
the variable with Cmy. Perl would produce a warning in this case to
the effect that, "A variable used within a block was used after that
block, but never declared or used before it. The enclosing scope
cannot see the same variable that exists within the enclosed block."
Alternatively, if this RFC is adopted, but nothing is done to alert
new Perl6 programmers about these possibly ambiguous cases, the
programmer would receive a "Use of undefined value" warning which
might suffice.
=item 2
In the "liberal" approach, perl can do what amounts to "inferring
declarations." To actually refer to it this way would be a
contradiction in terms, since a declaration is explicit, not inferred.
To implement the liberal approach, perl would detect all of the
undeclared variables used within a scope when it compiles that scope.
These variables would become available for use from the minute that
scope is entered. Thus, in the example above, $color is detected as
being a part of the enclosing scope before the interpreter ever
Re: Eliminate dynamic variables entirely?
[EMAIL PROTECTED] (Nathan Wiger) wrote on 14.08.00 in [EMAIL PROTECTED]:
Well, lexical variables don't belong to any package in Perl. They're not
in the symbol table, hence why others can't mess with them. That's why a
"my $var" is different from a "$pkg::var". The latter gets in the symbol
table, the former doesn't.
I think Perl'd profit from using a structure similar to the following:
1. Package variables $package::var, presumably you'd have to declare those
and the default would be
2. lexical variables,
except that different from the current way, you'd have access to a stack
of lexical symbol tables. (Doesn't mean it needs to be the same
datastructure internally, just so long as you can access it with the same
syntax.)
So you'd find a global var via $package::{'var'}, and a lexical var via
$STACK[3]{'var'} ($STACK[0] being where my() declares new variables, and
$STACK[$#STACK] the symbol table where top-level my() declares file-scope
variables).
Except for access to the symbol table, that's very similar to what other
languages have.
Furthermore, in the "more rope" department, it might be possible to make
local() work on my() variables this way.
MfG Kai
Re: RFC 97 (v1) prototype-based method overloading
Chaim Frenkel wrote: "PC" == Piers Cawley [EMAIL PROTECTED] writes: PC Chaim Frenkel [EMAIL PROTECTED] writes: Why would anyone want to select a different method based upon the arguments. PC Have you seen Class::Multimethods? This kind of despatch can be very PC useful. Of course, the existence of Class::Multimethods proves that it PC can be done already so there may be no need to put it in the core. You answered the HOW, not the WHY. The question for the audience is WHY, I would want to do this. (As a counterpoint. Dr. Myers argues very strongly against this.) There are a couple of reasons for overloading. simple arithmetic operations, you can use plus(int, int), plus(float, float). another approach is to use genericity like in eiffel, and the templates in C++, which is probably better in the sense that you only have one function ie plus(type, type). peter -- "Speak loudly, and carry a beagle!" -- Charles Schulz
Re: RFC 97 (v1) prototype-based method overloading
Why would anyone want to select a different method based upon the arguments. Have you seen Class::Multimethods? This kind of despatch can be very useful. Of course, the existence of Class::Multimethods proves that it can be done already so there may be no need to put it in the core. There's a definite need to put it in the core. Class::Multimethods is too slow. I'll be proposing this form of multiple dispatch and overloading in a forthcoming RFC. Damian
Re: RFC 98 (v1) context-based method overloading
David Nicol [EMAIL PROTECTED]: The other way C++ allows you to overload a named function is by return type. This is explicitly incorrect. The return type is not used in the resolution of an overloaded function. That's not to say that it wouldn't be nice to have in perl... -- John Porter
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
On 11 Aug 2000 16:22:33 -, Perl6 RFC Librarian wrote: Currently, Perl uses the C library Clocaltime() and Cgmtime() functions for date access. However, because of many problems, these should be replaced with two new functions, Cdate() and Cgmtdate() Gee, yet again, we'll get two virtually identical but still separate functions. The original RFC tried to get rid of that, and replace them by just one function. Why did this sneak back in? Why is it yet again not possible to get the local time in another time zone? -- Bart.
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
use strict
Yes it should be use strict qw(..); It would be wonderful if someone could invest in an RFC or two to propose the use of strict. I didn't intend to propose the use of such terms. I simply needed to put a handle on some things. - primitive data types; I used char, varchar, int, double as an SQL addict. - const or constant or whatever Additionally, there is need for proposals on syntax symmetry and module symmetry. Perl has many ways of doing the same things. I quite like it that way. It gives me some many ways and pleasures to toy around and then proudly confound my colleagues. On the other hand, my meat becomes some else's poison. Symmetry promotes expectancy. Expectancy is an expression of certainty, which is an attribute of quality. And quality, productivity. [EMAIL PROTECTED] on 08/14/2000 09:40:00 PM To: [EMAIL PROTECTED]@Internet cc: (bcc: Syloke Soong/Americas/NSC) Subject:Re: RFC 89 (v2) Controllable Data Typing The strict directive, is set to croak when an attempt to change the value of constant $str22 is made. Use of use strict(constdie); Overall the proposal looks good. However, I think this should just be "use strict 'constants'". This makes it consistent: use strict qw(vars subs constants); The mode of operation for strict is to die on errors. As such, the "die" in "constdie" is redundant. And while "constants" is longer than "consts", it's a word and much easier to remember (your brain chunks words but not non-words).* Then, if you just want to issue warnings, do something like "use warnings 'constants'". -Nate * However, if the keyword ends up being 'const' then 'consts' might be more appropriate.
Re: RFC 102 (v1) Inline Comments for Perl.
Kirrily Robert said: What relationship does this have to RFC 5 (multiline comments), and hasn't the discussion of inline comments occurred in detail already? There is a distinction, because the proposal for multiline comments requires (like all here docs) the opening and closing be on their own line -- thereby forcing multiline commenmts to be multiline. To clarify the distinction (as I see Glenn's proposal): #end-of-line comment, terminates at newline\n #inline comment, cannot contain a newline# #TOKEN; multiline comments: RFC is now frozen, so don't discuss this! TOKEN I'll just quietly duck down here in my bunker while the List "discusses" this :-) --Michael
Re: RFC 83 (v1) Make constants look like variables
On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote: Well, just to counter argue, I feel exactly the opposite way. I'd like the keyword to be "constant" instead of "const". I've always thought "const" was a needless save of 3 characters. Constants should be obvious to pick out. The inventors of UNIX, when asked "What was your biggest mistake?" replied "Spelling creat() without the 'e'". Ditto here, IMO. Amen. Which is the easiest for anyone to tell what's going on? my num $PI : constant = 3.1415926; my num $PI : const = 3.1415926; my num $PI =| 3.1415926; Admittedly, "const" is pretty darn close to "constant", so tolerable. But =| is way too obscure, I think. Not only obscure but backwards IMHO. Rather than using some weird assignment operator to modify the attributes of a scalar (after all, constancy is a property of the scalar), better the attributes should be verbose and explicit. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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: RFC 48 (v2) Replace localtime() and gmtime() with da
On Tue, Aug 15, 2000 at 12:08:52PM +0200, Bart Lateur wrote: On 11 Aug 2000 16:22:33 -, Perl6 RFC Librarian wrote: Currently, Perl uses the C library Clocaltime() and Cgmtime() functions for date access. However, because of many problems, these should be replaced with two new functions, Cdate() and Cgmtdate() Gee, yet again, we'll get two virtually identical but still separate functions. The original RFC tried to get rid of that, and replace them by just one function. Why did this sneak back in? Why is it yet again not possible to get the local time in another time zone? You're right, there should be just one date/time routine. But it is *extremely* difficult to incorporate time zones in a portable fashion. They change at legislative whim. But if utcdate() (or whatever we call it) had a way to specify an offset from UTC, that would be just fine. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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: RFC 76 (v1) Builtin: reduce
Following the lead of the sort operator, it would be a little
simpler to see reduce expressions use $a and $b instead of
$_[0], $_[1].
E.g.
Summation:
$sum = reduce{$a + $b} 0, @numbers;
$sum = reduce sub{$a + $b},0, @numbers;
Production:
$prod = reduce{$a * $b}1, @numbers;
$prod = reduce sub{$a * $b}, 1, @numbers;
Following grep, map, sort, reduce should be able to
accept all these forms - currently the form seems to be like
sort than grep and map.
reduce $a + $b, @list # grep, map
reduce{$a + $b} @list # grep, map, sort
reducesum2 @list # sort
reduce sub{$a + $b}, @list # sort
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
Re: RFC 76 (v1) Builtin: reduce
On Tue, Aug 15, 2000 at 11:31:50AM -0500, Adam Krolnik wrote: Following the lead of the sort operator, it would be a little simpler to see reduce expressions use $a and $b instead of $_[0], $_[1]. The $a and $b of the sort comparator were A Bad Idea to begin with. There's nothing wrong with using the standard @_. The $a and $b just introduce yet another special case, which among other things makes it very hard to warn about dubious uses of users' variables named $a or $b. (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still consider the $ and $b to be warts.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 76 (v1) Builtin: reduce
Jarkko Hietaniemi wrote: The $a and $b of the sort comparator were A Bad Idea to begin with. Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't be used, or even a more standard $1 and $2. Either one makes it more obvious what's being operated on. It also fixes the "'use strict' ignores $a and $b problem" mentioned repeatedly on p5p. -Nate
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
Re: RFC 102 (v1) Inline Comments for Perl.
Glenn Linderman [EMAIL PROTECTED]:
An idea that produces a paired feeling would be to use one of the
paired character pairs, as in "#" and "#".
...the three paired character possibilities ("", "()", "{}")
There is at least one more: "[]".
And the Perlish thing to do would be to allow any of them, right?
#[ one comment # nested inside # another one. ]#
The competing suggestion for in-line comments was
to define "qc/comment/" as a syntax that evaporates. I don't like
that syntax, because it looks more like code than comment,
It *is* code. It's code that evaporates, which makes it a comment, too.
$foo = qw/foo bar/ qc/eat me/;
It is not clear whether such syntax would be easily readable within all
forms of expressions, without operators, as shown in the above example,
vs
$foo = qw/foo bar/ #eat me#;
It stands out as much as you want it to, which might be a lot, or none.
$foo = qw/foo bar/qc# EAT ME ;
Frankly, if I'm scanning source for comments, I'm more likely to be
looking for the string of interest, e.g. "eat me", than the tiny bit
of syntax that creates the comment. And ## is surely a tiny bit
of syntax. (Or else I let my editor look for comments; and /qc is
no harder to type than /#.)
Plus it has the advantage of not introducing any new syntax, only
the qc// operator.
But this has all been said before, and I apologize.
--
John Porter
Re: RFC 104 (v1) Backtracking
iVAN Georgiev [EMAIL PROTECTED]:
They behave similarly like , ||, and, or operator with one main
distinction they "backtrack" for example:
{ block1 } Bandthen { block2 };
This would be a good use of the to-be-liberated = operator:
{ block1 } = { block2 };
In any case, "andthen" doesn't seem like a good choice.
Other possibilities:
therefore
implies
segue
seq
so
--
John Porter
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? I guess it depends on what you think makes sense; but it seems to me that an array is a more fundamental data type; that it's easier (i.e. more efficient) to build associative arrays from arrays, than vice versa. -- John Porter
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: RFC 84 (v1) Replace = (stringifying comma) with =
At 03:53 PM 8/15/00 -0400, John Porter wrote: Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? I guess it depends on what you think makes sense; but it seems to me that an array is a more fundamental data type; that it's easier (i.e. more efficient) to build associative arrays from arrays, than vice versa. It's silly to throw either of them out. Perl might be many things, but a reductionist language it ain't... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Isn't that the way perl4 did it? I don't know what agony lwall and friends went through that made them change this behaviour though. It would be good for someone who does to speak up about it. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Um, no. Something about the relaxation of strictness in a special context (interpolation) makes me uneasy... -- John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On 15 Aug 2000, Perl6 RFC Librarian wrote:
This RFC proposes that C$x, C@x, and C%x be ditched and
replaced with C$x for everything.
my $foo = ('apples', 'oranges');
my $bar = ('apples' = 'crunchy', 'oranges' = 'juicy');
my $zot = 'bananas';
my $ret = junkem(\$foo, \$bar, $zot);
sub junkem {
my($a, $b, $c) = $_;
my $d;
unshift($$a, $c);
foreach($$a) {
push($d, $b-{$_});
}
return join(' ', reverse $d);
}
I have my doubts about decreasing line noise. :) Maybe not about making
Perl 6 extensible for future struct types, but line noise indeed...
Please excuse the silly example.
--
Mike Pastore
[EMAIL PROTECTED]
PS -
my @foo = ('apples', 'oranges');
my %bar = ('apples' = 'crunchy', 'oranges' = 'juicy');
my $zot = 'bananas';
my $ret = junkem(\@foo, \%bar, $zot);
sub junkem {
my($a, $b, $c) = $_;
my @d;
unshift(@$a, $c);
foreach(@$a) {
push(@d, $b-{$_});
}
return join(' ', reverse @d);
}
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Karl Glazebrook [EMAIL PROTECTED]: This RFC proposes that C$x, C@x, and C%x be ditched and replaced with C$x for everything. The only distinction left would be between things which are variables (prefixed by C$) and not-variables (subroutines and keywords). A useless distinction at the lexical level. Get rid of "$" too. x is a symbol; perl can look up what it means. -- John Porter
Re: English language basis for throw
On Mon, 14 Aug 2000 12:32:32 -0500, David L. Nicol wrote: I find "throw" to be a perfectly good synonym for "raise" an exception. The english language equivalent is a piece of steel machinery, when it breaks while running, which is said to "throw a rod" or "throw a bolt" depending of course on the nature of the broken item that comes flying out of the mechanism at dangerous and possibly inventor-fatal speeds. Your explanation makes it sound as if the program can just blow up in your face. I sure hope that error trapping goes in a somewhat more controlled manner. I find it preferable to "die" which has always struck me as morbid, even if it does echo the equally objectionable unix "kill." N to me, "die" just means it simply stops working. Nothing blowing up. Just to make sure some opposition is heard: I've always thought of "throw" as very silly word. To me, a program is much like a maze, a multilevel walk in an old castle. There are unexpected trapdoors, but as long as they stay closed, you can simply continue. If such a trapdoor open, you fall through, someimes through several floors, until somewhere you encounter a safety net: you were caught. You can continue from there. If there was no safety net, you keep falling, well, into the water, out of the castle (er, "program".) An error is not a ball. -- Bart.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Dan Sugalski wrote: The ultimate target of a program's source code is the *programmer*. Programmers, being people (well, more or less... :), work best with symbols and rich context. Stripping contextual clues out of code does the programmer a disservice. Then every proposal so far which would eliminate distinguishing symbols, and/or the things they distinguish, is on the wrong track, eh? Yep. -- John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Dan Sugalski wrote: Let's not move backwards and force people to work like machines. Instead, lets force machines to work like us. Hear, Hear! I feel that this is worth a "me too". Clayton -- Clayton Scott
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Tue, Aug 15, 2000 at 05:20:11PM -0400, John Porter wrote: Dan Sugalski wrote: The ultimate target of a program's source code is the *programmer*. Programmers, being people (well, more or less... :), work best with symbols and rich context. Stripping contextual clues out of code does the programmer a disservice. Then every proposal so far which would eliminate distinguishing symbols, and/or the things they distinguish, is on the wrong track, eh? Yep. Maybe. The point often missed is that the prefix carries information, it's not there just to annoy. If I have no prefixes and have code like this: foo = func(bar, zog) I have no idea what foo, bar, and zog are, without jumping back through the block beginnings, maybe even to the file level, to find the darn definitions. Compare with %foo = func($bar, @zog) I still don't know all but I do know more. "We want to get rid of linenoise because the other language X does not have linenoise" is kind of poor argument because it easily draws the retort "Well, you know where to find X is, then. This is Perl." -- John Porter -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 109 (v1) Less line noise - let's get rid of @%
This RFC proposes that C$x, C@x, and C%x be ditched and
replaced with C$x for everything.
Let me be the first to say "No!". I like this feature. I always have,
and always will. It's super-duper easy to glance at this code and tell
what is what:
@stuff = read_stuff;
foreach (@stuff) {
$$_ = 1;
}
while (($key, $val) = each %data) {
print "$key is $val\n";
}
This is one of the things I really like about Perl: being able to tell
what type of thing I'm looking at. Is is a list? A single value? A hash
of values? No sweat, look at the prefix.
Giving this up is a horrible, horrible idea and would be a tremendous
step backwards for Perl. If people don't like prefixes, there are plenty
of other alternative languages, such as C, C++, Java, and so on. And you
can always embed Perl in C, if you just want to regexp stuff without all
the Perl.
Prefixes aren't for the computer. They're for us humans.
-Nate
P.S. Anyone who hasn't, please read this email from TomC. I think you'll
understand prefixes are a GOOD THING:
http://www.mail-archive.com/perl6-language@perl.org/msg00329.html
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Today around 2:28pm, Nathan Wiger hammered out this masterpiece:
: This RFC proposes that C$x, C@x, and C%x be ditched and
: replaced with C$x for everything.
:
: Let me be the first to say "No!". I like this feature. I always have,
: and always will. It's super-duper easy to glance at this code and tell
: what is what:
:
: [ snip easily read code :]
I agree.
: This is one of the things I really like about Perl: being able to tell
: what type of thing I'm looking at. Is is a list? A single value? A hash
: of values? No sweat, look at the prefix.
Along similar lines, what happens to function prototypes?
sub my_func($$$) {}
That isn't too helpful if you're using it like this:
myfunc( "Scalar", [ "Array", "Ref" ], { Hash = 'Ref' } );
--
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: RFC 109 (v1) Less line noise - let's get rid of @%
Jarkko Hietaniemi wrote: The point often missed is that the prefix carries information, it's not there just to annoy. ... I still don't know all but I do know more. Yes. OTOH, if it doesn't add *enough* information, it's not cost- effective. Most of proposals, such as highlander types and this 109, reduce the amount of info carried by the symbol to the point that it isn't worth having. Furthermore, if the OO nature of perl, as foreshadowed by perl5's tie-ing and lvalue subs, realizes its full potential, then being a "scalar", as indicated by a $, conveys essentially zero information. "We want to get rid of linenoise because the other language X does not have linenoise" is kind of poor argument because it easily draws the retort "Well, you know where to find X is, then. This is Perl." I agree. I've never used that argument. At least, not in earnest. -- John Porter Aus tiefem Traum bin ich erwacht.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Nathan Wiger wrote: This is one of the things I really like about Perl: being able to tell what type of thing I'm looking at. Is is a list? A single value? A hash of values? No sweat, look at the prefix. I appreciate the point. I discuss it in the RFC and why I think it no longer works. I hope people will actually read the RFC before coming back with these canned responses which I (and presumably everyone else on this list) am completely familiar with. I used to believe that too! Honest... I am looking forward to reading some *real* criticisms... Karl
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. I initially was thinking this too, but there's a major problem: print "Your stuff is: @stuff\n"; I want this to *always* print out the _value_ of @stuff, even if it's unititalized. Perl's already smart enough. I think getting in the habit of writing: $email = '[EMAIL PROTECTED]'; Is the better thing to do. -Nate
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
"Jonathan" == Jonathan Scott Duff [EMAIL PROTECTED] writes: Jonathan Isn't that the way perl4 did it? I don't know what agony lwall and Jonathan friends went through that made them change this behaviour though. It Jonathan would be good for someone who does to speak up about it. It permits "action at a distance". A program that originally didn't have @stonehenge in print "email me at [EMAIL PROTECTED]" may someday later introduce a @stonehenge, and now this statement means something completely different. What would be NICE is to treat @stonehenge here as *always* a variable (similar to the way scalars are treated), which was actually implemented in one of the perl5 alphas, but changed to the current behavior when it made too many programs print "merlyn.com" for the above! So, I'd support a modification to the RFC that does what Larry intended here: array interpolation should work exactly like scalar interpolation -- 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 109 (v1) Less line noise - let's get rid of @%
Dan Sugalski wrote: Tossing the worthless and confusing ones is good. Tossung the useless and distinguishing ones is bad. Uh, which ones did you have in mind, by "useless and distinguishing"? ;-) -- John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Jon Ericson wrote: Why not change @x so that it can represent other types of arrays? For instance: my @x; # standard Perl array my @y[2, 3];# 2x3 matrix (syntax guess) my FIFO @z; # FIFO stack (another guess) This is ENTIRELY my point: the more things a '@' can represent, the LESS information it carries; and there will come a point -- when perl6 is released, if not sooner -- when the symbol will be essentially content-free. So get rid of it. It's a waste. -- John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
At 05:53 PM 8/15/00 -0400, John Porter wrote: Dan Sugalski wrote: Tossing the worthless and confusing ones is good. Tossung the useless and distinguishing ones is bad. Uh, which ones did you have in mind, by "useless and distinguishing"? ;-) D'oh! (or is that now D::oh?) I meant _useful_ and distinguishing. Really I did... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
On Wed, Aug 16, 2000 at 08:01:12AM +1000, Damian Conway wrote: I don't think the :lvalue is needed. This isn't really an attribute - if someone writes: $r-name = 'Mithrandir'; there's no confusion that it's assigning it. Ah, but there's definitely a confusion as to whether it's *meant* to be assignable. What if I (as the class designer) want to give you read access but not write access to an object's name? Or if I'm in truly evil mood and make assignments mean push() and reads mean pop()... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Dan Sugalski wrote: Generality good. For many things, yes. For computers, say. For people, no. Generality bad. Specificity and specialization good. People aren't generalists. They're a collection of specialists. The distinction is important. I'm sorry if I don't find this argument convincing. This argument suggests that *every* type carry a distinguishing prefix symbol -- including ones to distinguish between numbers and strings, say. Of course, you don't mean this. A balance must be struck. And while we're looking for the equilibrium, let's not prejudicially presume that "no symbols" is not an option. Even assuming highlander types, the punctuation carries a rather significant amount of contextual information very compactly. Yep. So, what's the gripe with it? Other than that it's not what you're used to, I mean. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. -- John Porter Aus tiefem Traum bin ich erwacht.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Dan Sugalski wrote: If the symbol becomes content-free, perhaps the problem is with what made it useless, not with the symbol itself... Yes! -- John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
John Porter wrote: Dan Sugalski wrote: If the symbol becomes content-free, perhaps the problem is with what made it useless, not with the symbol itself... Yes! But that's not to say I agree that certain proposals which would have the effect of rendering the symbol useless are inherently bad. (Hmm... not enough negatives...) I support, tentatively, certain proposals which could render the variable prefix symbols useless. But I guess that's all I have to say on the subject. -- John Porter
Re: RFC 76 (v1) Builtin: reduce
Jarkko Hietaniemi wrote: On Tue, Aug 15, 2000 at 11:31:50AM -0500, Adam Krolnik wrote: Following the lead of the sort operator, it would be a little simpler to see reduce expressions use $a and $b instead of $_[0], $_[1]. The $a and $b of the sort comparator were A Bad Idea to begin with. There's nothing wrong with using the standard @_. The $a and $b just introduce yet another special case, which among other things makes it very hard to warn about dubious uses of users' variables named $a or $b. (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still consider the $ and $b to be warts.) And anyhow, this will work just fine (see RFC 23): $sum = reduce ^a + ^b, @numbers;
Re: RFC 76 (v1) Builtin: reduce
(Yes, there is a small aesthetic edge in using $a vs $_[0], but I still consider the $ and $b to be warts.) And anyhow, this will work just fine (see RFC 23): $sum = reduce ^a + ^b, @numbers; I have been amply reminded of this, thanks :-) (Too little time to spend on RFCs...) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 109 (v1) Less line noise - let's get rid of @%
All variables should be C$x. They should behave appropriately
according to their object types and methods.
No thanks. I frequently use variables $foo, @foo, and %foo at the same
time when they contain the same information in different formats. For
example:
$args = 'first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ = ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely. I'd be very upset if this idiom went away.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Dan Sugalski [EMAIL PROTECTED] writes: If the symbol becomes content-free, perhaps the problem is with what made it useless, not with the symbol itself... Wholeheartedly agreed. If something is an array, it should start with @. If we're adding language changes that introduce arrays that don't start with @, that's the mistake. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 83 (v1) Make constants look like variables
Jonathan Scott Duff wrote: On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote: Well, just to counter argue, I feel exactly the opposite way. I'd like the keyword to be "constant" instead of "const". I've always thought "const" was a needless save of 3 characters. Constants should be obvious to pick out. The inventors of UNIX, when asked "What was your biggest mistake?" replied "Spelling creat() without the 'e'". Ditto here, IMO. Amen. Which is the easiest for anyone to tell what's going on? my num $PI : constant = 3.1415926; my num $PI : const = 3.1415926; my num $PI =| 3.1415926; Admittedly, "const" is pretty darn close to "constant", so tolerable. But =| is way too obscure, I think. Not only obscure but backwards IMHO. Rather than using some weird assignment operator to modify the attributes of a scalar (after all, constancy is a property of the scalar), better the attributes should be verbose and explicit. Yes, I agree too. I'm going to submit a v2 of this RFC shortly, which will clarify a few points about the use of const with lists and hashes and make the change to attribute notation, but otherwise will be pretty much the same. Since there hasn't really been concensus on this issue, those interested in alternative notation, or a wider array of scenarios where constant can be used, should submit a counter-RFC.
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Some time ago, this is how it was done, to stay backwards compatible. In recent versions (the farthest I can tell is 5.004) it became a fatal error. I don't think we should go backwards. If someone uses @, they mean array. A warning should be emitted, but it should print a blank string. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 06:04 PM 8/15/00 -0400, John Porter wrote: Dan Sugalski wrote: Generality good. For many things, yes. For computers, say. For people, no. Generality bad. Specificity and specialization good. People aren't generalists. They're a collection of specialists. The distinction is important. I'm sorry if I don't find this argument convincing. This argument suggests that *every* type carry a distinguishing prefix symbol -- including ones to distinguish between numbers and strings, say. Numbers and strings really aren't different things, at least not as far as people are concerned. They are for machines, but computer languages ultimately aren't for machines, they're for people. Of course, you don't mean this. A balance must be struck. And while we're looking for the equilibrium, let's not prejudicially presume that "no symbols" is not an option. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. Even assuming highlander types, the punctuation carries a rather significant amount of contextual information very compactly. Yep. So, what's the gripe with it? Other than that it's not what you're used to, I mean. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. Yes, they do. People write source. People read source. People are the most important piece of the system. The computer can be made to cope with the syntax, whatever the syntax is. People can't be made to cope nearly as easily, nor to nearly the same degree. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 90 (v1) Builtins: zip() and unzip()
Lightning flashed, thunder crashed and Perl6 RFC Librarian [EMAIL PROTECTED] whispered: | =head1 TITLE | | Builtins: zip() and unzip() | [snip] | | its arguments. Cunzip($list_size, \@list) would reverse this operation. | [snip] | | If the list to be unzipped is not an exact multiple of the partition size, | the final list references are not padded--their length is one less than | the list size. For example: | | @list = (1..7); | @unzipped_list2 = unzip(3, \@list); # ([1,4,7], [2,5], [3,6]) This wording is confusing. Is $list_size or "the partition size" supposed to be the length of each list, or the number of lists? The way it is described leads me to think it should be the length of each list, but this example shows it being the number of lists. I would expect the @unzipped_list2 would return ([X,Y,Z], [A,B,C], [M]), although I can't wrap my mind around which values should go where yet. It makes more sense for it to be the number of lists, in which case @unzipped_list should be ([1,4], [2,5], [3,6]) not ([1,3,5], [2,4,6]). -spp
Re: MATRIX implementation (and context-based overloading)
This sort of thing is an excellent example of how method selection based on calling context can help. When somebody wants to overload existing keywords for their slick new type, with overloading based on context they don't have to touch the internals of the current methods at all. raptor wrote: ]- One possible implementation of MATRICES is for example : As I read in perlguts-illustrated the array is represented as a array of POINTERS i.e. (pointer to $a[0], pto $a[1], pto $a[3], pto $a[n]) then we can have f.e. "matrix" : matrix 10x5, @a; this just reorders the list in the following LIST-ARRAY structure : (pto $a[0] .. $a[9]) --next- (pto $a[10] .. $a[19]) ---next- () now we have chained-arrays. The benefit : (@a is now internally known for perl as MATRIX) push @a,@b; will push one by one all elements of @b into correspondending rows in @a matrix push is now executed in MATRIX CONTEXT. If you gotcha the idea then all splice, pop,shift, unshift will do their correspodending roles. (offcource there is some glitches such as what happen if the @b array is smaller/bigger the necessary elements for the matrix - then we can have fillwith zeros, with default value ... etc) THE other operator "unmatrix" just convert the matrix back to array.. We can easly access say element 250 for example like $a[250] 'cause the exact position is is easy calculated, offcource the access will be little bit slower than normal array. WHAT HAPPEN with HASHES ?!? May be we can look at them as TABLES... = iVAN [EMAIL PROTECTED] = -- David Nicol 816.235.1187 [EMAIL PROTECTED] :wq
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote: The ultimate target of a program's source code is the *programmer*. Programmers, being people (well, more or less... :), work best with symbols and rich context. Stripping contextual clues out of code does the programmer a disservice. We're at the point where we don't have to cater to the limitations of the computer hardware. That means we'll be better off if we cater to the limitations (and strengths!) of people's wetware. Let's not move backwards and force people to work like machines. Instead, lets force machines to work like us. Exactly! I would also like to remind everyone that, despite abandoning backwards compatibility with programs, we should by no means abandon backwards compatibility with Perl programmers. Removing the special symbols would be quite a shock to most Perl programmers (including me), and we don't want to alienate those who know Perl. I say these things for purely selfish reasons; I like Perl, and want it to look much the same as it does now. Perl is a wonderful language. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
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: English language basis for throw
At 05:06 PM 8/15/00 -0400, John Porter wrote: I think about the word some OO gurus use: "raise". I think that came from the kernel or hardware people before OO was around. Something about raising and lowering IPLs. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? No, neither proposal makes sense. Arrays can be stored compactly and accessed and iterated through quickly, because they can take advantage of the fact that they are always indexed by an integer. You could remove the array/list data type and rely on Perl to try and implement hashes indexed by integers as a list, but that would introduce a lot of complexity for little real benefit.
Re: English language basis for throw
At 05:33 PM 8/15/00 -0400, John Porter wrote:
The thing I don't like about C++/Java try/catch syntax is the way
the blocks are daisychained. That is not intuitive to the flow.
I find it quite intuitive :-)
The exception handlers should be more closely bound -- syntactically --
to the try block. A switch statement would be closer; but I think an
OO syntax would be better. You know, something like
try {
cough "outa here";
catch {
matawba = { sustain; },
ebola = { overrule; },
{ punt; }
}
}
What interpretation should be placed on statements in the try block
following a catch block?
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 104 (v1) Backtracking
On Wed, Aug 16, 2000 at 08:26:26AM +1000, Jeremy Howard wrote: Doesn't RFC 82 (Make operators behave consistantly in a list context) provide this functionality? This is perfectly valid under that proposal: @result = @a || @b; Which applies '||' component-wise to elements of @a and @b, placing the result in @result. I'm no Prolog guru, so feel free to correct me if I'm missing something here. I think you're missing the backtracking part (I'm no guru either). As I understand things: BLOCK1 andthen BLOCK2 evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2 evaluates to "false", then BLOCK1 is re-evaluated. Er, let me see if I can write the logic better: 1. eval BLOCK1 2. if "false", stop, else goto 3 3. eval BLOCK2 4. if "true", stop, else goto 1 It's kind of an all-or-nothing expression with side effects (evaluating the blocks). This sort of logic can be extended to N blocks too. Though I think if we're going to support backtracking like this, we'll need to support the cut operator as well (! in prolog) (Note the only prolog I've done was about 10 years ago for about 2 weeks and about 2 years ago for 2 or 3 weeks in a programming languages class at a university) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote: Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) accessed and iterated through quickly, because they can take advantage of the fact that they are always indexed by an integer. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 109 (v1) Less line noise - let's get rid of @%
I hope people will actually read the RFC before coming back with these
canned responses which I (and presumably everyone else on this list)
am completely familiar with. I used to believe that too! Honest...
I am looking forward to reading some *real* criticisms...
Ok, here goes. First off, I *did* read the RFC. I never respond before
reading. Personally, I wish people would quit coming up with these silly
"let's drop the prefixes" RFC's that everyone on this list is completely
familiar with.
Also in modern programming, lists are not longer simple
lists, neither are hashes, we have multidimensional arrays,
FIFO stacks, LIFO stacks, semi-infinite lists, etc.
Yeah, and isn't it cool that Perl gives you easy access to using and
understanding such complex data structures:
print @{ $cars-{$model} };
That "junk" makes it easy to see that you're derefencing a hashref that
contains a key which is pointing to an array. How is this:
print cars-model;
any clearer? Nicer to look at? Maybe for some. Not for me, I like the
former. Maybe it doesn't let you know exactly what you're getting, but
you're a lot closer. And this:
print "Welcome back, $fullname, to $website!\n";
is MUCH better than this:
print "Welcome back " . fullname . " to " . website . "!\n";
Ugly. Plus, is fullname a scalar? Array? Hash? Sub? Builtin? Well, it
looks like you have to guess, unless you wrote the whole program, which
you probably didn't.
Don't overlook the simple benefits of prefixes.
Those days are gone. Perl 5 introduced the idea of Objects
and now any variable can be one of ten million possible
types all of very different behaviours.
Not true!! Only $scalars can hold objects. Now, @arrays and %hashes can
hold groups of objects, but only $scalars can hold objects.
I used to think this was bad also, and that objects should have their
own prefix, like *. So:
*object = new CGI;
print *object-param($name);
That makes it easier to see what objects are, true. But that's not the
real problem.
The real problem is that we lack true object polymorphism. That is,
objects are useless in number and string contexts. This is the problem
that needs to be addressed. I've submitted RFC's 49 and 73 on this, and
have another one coming. I hope you'll read them.
Please, nobody submit an RFC on the * idea. It's bad, and here's why:
@stuff = (*object, $number, *filehandle);
foreach ( @stuff ) {
print "Got $_\n";
}
If you have a separate prefix and type for objects, then this will have
to fail with "Attempt to stick object whatzitz in scalar whatzitz". Bad.
However, if you have object polymorphism, then you don't have this
problem. Objects are automatically converted to numbers and strings
on-demand. The internals people are doing some really interesting stuff
along these lines.
To summarize, you should read RFC's 49, 73, 28, and the link to TomC's
email I sent you. These address the real problems, and not the symptoms.
Maybe the prefix system isn't perfect, and maybe needs improvement. But
I don't see how eliminating it can possibly count as improvement.
-Nate
Re: RFC 109 (v1) Less line noise - let's get rid of @%
At 03:14 PM 8/15/00 -0700, Russ Allbery wrote:
All variables should be C$x. They should behave appropriately
according to their object types and methods.
No thanks. I frequently use variables $foo, @foo, and %foo at the same
time when they contain the same information in different formats. For
example:
$args = 'first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ = ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely. I'd be very upset if this idiom went away.
What he said. Several things have occasionally struck me as standing
improvement in Perl; this has never been one of them. It's always been
very intuitive and easy to understand for me.
Methinks the language list is starting to hit the ozone layer.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
At 02:44 PM 8/15/00 -0700, Nathan Wiger wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Less DWIM, please. I initially was thinking this too, but there's a major problem: print "Your stuff is: @stuff\n"; I want this to *always* print out the _value_ of @stuff, even if it's unititalized. Arrays aren't uninitialized. They contain zero or more scalars, some of which may be uninitialized. Perl's already smart enough. I think getting in the habit of writing: $email = '[EMAIL PROTECTED]'; Is the better thing to do. Yes! I think of the quotes as: ' - for strings not doing any variable interpolation " - for strings doing interpolation, or including digraphs I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. -- Peter Scott Pacific Systems Design Technologies
Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Jarkko Hietaniemi wrote: On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote: Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) my int @a: sparse; $a[1_000_000_000] = 'Yes, really!' # :P OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet. My point is that arrays *can* be stored compactly, not that they always *are*. Another type of array storage is that required for lazily generated lists (see RFC 81) http://tmtowtdi.perl.org/rfc/81.pod
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 05:41 PM 8/15/00 -0500, Jarkko Hietaniemi wrote: No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) Now, now, there have been credible proposals for sparse arrays, you know that... -- Peter Scott Pacific Systems Design Technologies
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: RFC 104 (v1) Backtracking
As I understand things: BLOCK1 andthen BLOCK2 evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2 evaluates to "false", then BLOCK1 is re-evaluated. So how is that different from: do BLOCK1 until do BLOCK2 ???
Re: subroutines ==? methods
The difference is one of use, not one of meaning. Why not extend "method" to be any subroutine, just as we have apparently extended "subroutine" to include "function" by not acknowledging any distinction there either? In fact, Class::Multimethods *doesn't* distinguish methods and subroutines. Neither will my forthcoming multiple dispatch RFC. Damian
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
Damian Conway wrote:
Ah, but there's definitely a confusion as to whether it's *meant*
to be assignable.
What if I (as the class designer) want to give you read access but not
write access to an object's name?
I think this misses the mark. We're talking about functions, right?
:lvalue won't save you from the situation you describe:
$r-func = $x; # whew! no :lvalue saves us
$r-func($x); # but not from this! oh no!
What you have to do is write the function correctly:
sub func {
die "assigning to func attempted" if @_;
$ME-{STATE}-{func}; # return "func" value
}
Now, if this is what you want, add a :readonly attribute:
sub func : readonly {
# auto-die if @_ seen
$ME-{STATE}-{func};
}
This saves you from both:
$r-func = $x; # whew! having :readonly
$r-func($x); # dies for both of these
-Nate
Re: Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) my int @a: sparse; I see: you have a time machine and I don't. So very unfair... $a[1_000_000_000] = 'Yes, really!' # :P OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet. My point is that arrays *can* be stored compactly, not that they always I smell...n-level bitmaps? *are*. Another type of array storage is that required for lazily generated lists (see RFC 81) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL Currently, internal time in Perl is maintained via Ctime, which is PRL highly system-dependent. On some systems, this is relative to the UNIX PRL epoch, while others use their own epochs (MacPerl uses 1904, for PRL example). PRL All versions of Perl on all platforms should maintain time both PRL internally and externally as seconds since the UNIX epoch (00:00:00 01 PRL Jan 1970 UTC). -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@error
Peter Scott wrote: I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. We could invent qv/interpolate variables/ qd/interpolate digraphs/ qs/interpolate scalars/ qa/interpolate arrays/ qh/interpolate hashes/ qr/intepolate -/ qx/replace with stdout of execution of string as command/ Then, define qvd/same as qq interpolate variables and digraphs/ qvdsahr/interpolate everything/ One possible problem with this solution is that it potentially consumes quite a few symbols that start with q. Maybe it should be: q/interpolate variables/v q/interpolate digraphs/d q/interpolate scalars/s q/interpolate arrays/a q/interpolate hashes/h q/intepolate -/r q/same as qq: interpolate variables and digraphs/vd q/interpolate everything/adhrsv In that case, qq// and qx// should be translated to q/interpolate variables and digraphs/vd q/replace with stdout of execution of string as command/x by p52p6, I suppose. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Russ Allbery wrote:
All variables should be C$x. They should behave appropriately
according to their object types and methods.
No thanks. I frequently use variables $foo, @foo, and %foo at the same
time when they contain the same information in different formats. For
example:
$args = 'first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ = ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely. I'd be very upset if this idiom went away.
It's already withered away some in perl5. Functions can return lists or
scalars with no distinguishing marks, which was harmless until the
advent of lvalue subs. Now you have $object-listmember = (1,2,3);
$object-scalarmember = 42;. Anyone up for an RFC on allowing a leading
@, $, or (?) % to set the context of a function call? ;-) (Maybe there's
one already, I haven't been keeping track.)
I would very much hate to see the prefixes go away or merge into a
single one, but I'm not so sure I agree with Russ. I've had to teach
lots of beginners that even though $x refers to scalar x, $x{...} refers
to %x, but don't think of it that way because the $ is saying what value
you're getting back, not which variable you're using, unless you're
calling a function, or...
I'll just say I wouldn't mind having a stricture forbidding $x and %x in
the same package. I've fairly frequently used code like the above, but I
don't really like that code in the first place because the only purpose
for the $args and @args is as temporaries. I like the way mjd describes
it: this is "synthetic" code. If you really did have distinct
long-lived variables with the same name, then I bet it would be
confusing. Either you're maintaining some consistency invariant between
them, and you have to do that manually, or they're unrelated and they'll
collide in readers' brains.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Steve Fink [EMAIL PROTECTED] writes:
I would very much hate to see the prefixes go away or merge into a
single one, but I'm not so sure I agree with Russ. I've had to teach
lots of beginners that even though $x refers to scalar x, $x{...} refers
to %x, but don't think of it that way because the $ is saying what value
you're getting back, not which variable you're using, unless you're
calling a function, or...
This falls firmly in the category of things that are powerful for
experienced users of the language but may be somewhat difficult to learn.
I don't think Perl has being easy to learn as it's primary goal, nor
should it.
I'll just say I wouldn't mind having a stricture forbidding $x and %x in
the same package.
Ugh. I'll definitely never use it. I don't object *provided* that it
doesn't become like the other strictures, things that people expect all
Perl scripts to use; I think it's an essentially worthless constraint.
I've fairly frequently used code like the above, but I don't really like
that code in the first place because the only purpose for the $args and
@args is as temporaries. I like the way mjd describes it: this is
"synthetic" code. If you really did have distinct long-lived variables
with the same name, then I bet it would be confusing.
I do this all the time and I don't find it confusing. Please let's not
mandate programming style. Often times the difference between the
variables changes some as the program proceeds, but context makes it quite
clear what's going on.
This strikes me as the same sort of meaningless style guideline as "all
variables must have names that are at least five characters long."
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
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: RFC 104 (v1) Backtracking
Jeremy Howard writes: @result = @a || @b; Which applies '||' component-wise to elements of @a and @b, placing the result in @result. *Ptui* That's not how *I* want || to behave on lists/arrays. I want @result = @a || @b; to be like: (@result = @a) or (@result = @b); That's what all my students keep expecting it to mean. Nat
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
(-internals removed from the CC list) [EMAIL PROTECTED] writes: All calendar systems are arbitrary. Yup. So let's use Larry's birthdate-and-time as the epoch marker. Seriously, stick with 1970 (if we need an arbitrary marker, no reason it can't be a familiar one) and extend date/time values to be BigSoddingInts. That'll mean we're not screwed by the +/- 69.summat year problem that will hit the rest of civilization in 2038, and we can do useful calculations like "number of days since Queen Victoria ascended to the throne" without wrapping around in our int space. Nat (BigInts are not an internals headache, so I'm not bothering the internals list, which is right now debating the difference between arrays and matrices)
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Perl6 RFC Librarian writes: =head1 TITLE Less line noise - let's get rid of @% I have some problems with this RFC: * you misunderstand the purpose of $ and @, which is to indicate singular vs plural. You say a $ indicates a string or number, but really it indicates a single thing. Similarly @ isn't just a variable marker, it's used to indicate that you get multiple things: @foo[2..10] @$foo * current typing provides rudimentary compile-type checking. Saying: $foo = (1,3,5); gives a warning. Saying: %foo = "Nat"; gives a warning. You'd lose that. To get it back you'd need verbally-typed variables: $foo :scalar = (1,3,5);# to get the warning and even then it's not necessarily going to be possible to make that elicit a warning at compile-time. * no sample code. If you're proposing something as big as this, I *really* want to see how it's going to change the language. Take an existing 30 line program that does lots of work with variables and convert it. Show me how it affects things like slices. I want to make sure that code that is currently easy doesn't become hard. * you complain that @foo will become more meaningless once we have different data structures that act as collections. You don't consider using @foo for those, though: my @foo : FIFO = (4,5); This fits in with my personal vision of how Perl6 will handle new data types: better support for tie, basically. You can plug in your own C or Perl code to implement new types that masquerade as scalars, arrays, or hashes. Someone else suggested this in the thread, and you treated it as already dealt with in the RFC, but I don't think it's dealt with at all. I can't see how saying my @foo : SOME_TYPE_THAT_IMPLEMENTS_ARRAY_OPERATORS = (4,5); is going to debase the meaning of '@'. Nat
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
"PS" == Peter Scott [EMAIL PROTECTED] writes: I want this to *always* print out the _value_ of @stuff, even if it's unititalized. PS Arrays aren't uninitialized. They contain zero or more scalars, some of PS which may be uninitialized. I don't know if it is still true. But at one point in perl's life defined(@arr) was false before anything was assigned to the array. At this point this is highly frowned upon. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 84 (v1) Replace = (stringifying comma) with =
John Porter writes:
I think as long as equivalent (and better!) functionality is available,
through equivalently terse syntax, who's to care? Why is
$h{'foo'} = 'bar';
instrinsically preferable to
assoc( %h, 'foo', 'bar' );
I'm horrified you have to ask this question.
Perl makes easy things easy. Hashes are bloody useful, as the last
decade of Perl has borne out. They deserve syntactic support because
they're used a lot and are worthy of a shorthand.
Anybody who seriously suggests that something that is commonly used in
Perl should become *harder* (also aka longer to type) needs mental
realignment.
There are many bad ways to do things, and I think this is one of them.
Nat
Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)
Nathan Torkington wrote: Jeremy Howard writes: @result = @a || @b; Which applies '||' component-wise to elements of @a and @b, placing the result in @result. *Ptui* That's not how *I* want || to behave on lists/arrays. I want @result = @a || @b; to be like: (@result = @a) or (@result = @b); That's what all my students keep expecting it to mean. Note that RFC 82 (http://tmtowtdi.perl.org/rfc/82.pod) proposes that _all_ operators behave the same way in a list context. To me, this consistancy would be a real win. The behaviour you're discussing is described in RFC 45. RFC 45 proposes a special case for the || operator, which is only using its short-circuiting functionality, not its 'or' functionality. In this case I would think that using an explicit 'if' would be more appropriate. I'm working with the maintainer of RFC 45 at the moment to see if we can get the consistency of component-wise behaviour in a list context without losing the ability to short-circuit in an assignment. A potential compromise would be to say that RFC 82 only applies to operators that do not short-circuit. However, my view is that the loss of consistency through such a step would be a substantial source of confusion. It would also mean that overloaded operators with a lazily evaluated parameter would not work in a consistent manner.
Re: RFC 104 (v1) Backtracking
At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote: Jeremy Howard writes: @result = @a || @b; Which applies '||' component-wise to elements of @a and @b, placing the result in @result. *Ptui* That's not how *I* want || to behave on lists/arrays. I want @result = @a || @b; to be like: (@result = @a) or (@result = @b); That's what all my students keep expecting it to mean. Seconded. It seems obvious that @a should be the whole array @a, not an iteration over its elements. If I want to iterate over @a, I should have to do so explicitly, with a for() or map(). --- Mark Cogan[EMAIL PROTECTED] +1-520-881-8101 ArtToday www.arttoday.com
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@error
Peter Scott wrote: I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. How odd, I've only very rarely needed this. I don't mind the extra typing in the few situations it has come up. I'd rather the extra typing than YAQO (yet another quoting operator). Nat
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. Unfortunately, the valid range of time supported is easily determined, and disturbingly short: Into the future: to next December 31st or June 30th, whichever is closer. Into the past : to past January 1st or July 1st, whichever is closer. Leap-seconds are a PITA for generic time routines. chaim -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On Tue, 15 Aug 2000, Buddha Buck wrote: Leap-seconds are a PITA for generic time routines. Not really. They don't happen very often so you simply have a subroutine that has them all (this is how SLALIB does it). The pain is that you have to release a new version of perl each time a new leap second is added :-) -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
Nathan Wiger writes: So the proposal is: make the dangerous one the default. I don't think that's a good idea. You're going to have to explain to me how these differ in their dangerousness: Nathan, you misunderstand Damian. What's dangerous is making every subroutine lvaluable. He's all for making lvaluable subroutines work intelligently is one thing. He thinks it's not a good idea to make all subs lvaluable. Not every subroutine corresponds to a method call exposing object-internal data. Most of my subroutines *do* something and make no sense to be called lvaluably. Explicit marking the compiler pick up assignments to non-lvaluable subroutines. It makes sense to explicitly mark the rare cases (:lvalue), rather than the common (:no_assignment). Nat
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Buddha Buck [EMAIL PROTECTED] writes: Leap-seconds are a PITA for generic time routines. Unix time ignores leap seconds. POSIX basically says "don't worry about them" and by and large that works. It means your system clock drifts a little over time and then gets corrected back by xntpd or something, but in practice time on a Unix clock is monotonic. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Thus it was written in the epistle of Russ Allbery, This falls firmly in the category of things that are powerful for experienced users of the language but may be somewhat difficult to learn. I don't think Perl has being easy to learn as it's primary goal, nor should it. Russ, Would mind saying that again? It's been said much too seldom around here and it's really refreshing to heard it put into works. Being easy to learn is not Perl's main goal. That goes in with Being a perfect CS language is not Perl's main goal. I don't know for sure what Perl's main goal is, but it's definitely significant to Perl to make life easier and it has done that. The prefixes and context sensitivity make Perl easier to read and to write and the fact that it makes better use of the entire printable set is an asset and not otherwise :-). minor rant I had a long discussion on another list with folks who were preaching that regexen were good because they were really powerful despite being difficult to read. I say that they don't have to be difficult to read. They're a language just like everything else. How long did it take before you could read your native language? Years. But it doesn't seem so difficult now. Why do folks feel that if they have to put out a little effort to learn something that it's a horrible thing? /minor rant Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == It is true that Fourier had the opinion that the principal aim of mathematics was public utility and explanation of natural phenomena; but a philosopher like him should have known that the sole end of science is the honor of the human mind, and that under this title a question about numbers is worth as much as a question about the system of the world. -- Jacobi, Carl == Deep thoughts to be found at http://www.southern.edu/~ashted
