Re: RFC: println()
[Reply-To set to [EMAIL PROTECTED]] Ed Mills wrote: I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; instead of print "$textvar\n"; Ever so much easier to read and write, prints the arg and appends \n. You can currently get this behaviour with print if you set $\ = "\n". I expect perl 6 to look more like perl 5 than Pascal. Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Sun, Aug 06, 2000 at 01:10:23PM -0700, Nathan Wiger wrote:
So you see why we need a persistent format() function. However, I think
your real issue is a one-time call that just changes the format
temporarily:
print $date-strftime('%H:%M'); # print the time
print "$date"; # without touching this
Indeed.
I'll put strftime() back in, I think that's probably the best thing for
this.
strftime sounds like a real Unixism to me. 'set_format' and 'format' looks
more neutral and at least as effective.
-- Johan
Re: Treating filehandles like strings
...and as for matching regexen against streams, I have a more general proposal for matching against subroutines that should allow for that as a special case. Damian
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Damian Conway sent the following bits through the ether:
Rather than continue to argue the details, why don't people post some
examples of code where they feel these lazy lists might be useful, and
let's see if there aren't already good alternatives.
It should be noted that "infinite" lazily-evaluated lists can be used
in Perl 5 in a perlish way with careful use of Tie::Array and
closures.
I've got an example of this in my poorly-coded Functional module[1],
which allows things like:
take(10, filter("prime", integers))
[yes, that is perl ;-] ... (which is done lazily)
Anything to make this easier to do in Perl 6 is welcomed ;-)
Leon
[1] http://www.astray.com/Functional/
--
Leon Brocard.http://www.astray.com/
yapc::Europe - September 22-24 London - http://yapc.org/Europe/
... Error 404: .signature generator ran out of tuits
Re: Safer OO inheritance
Bart Lateur [EMAIL PROTECTED] writes:
The problem is that you can't safely subclass a class, without examining
it's source, just to make sure that your instance fields don't clash
with any private fields of the mother class.
Well...let's think twice. What has the reputatin of being a bug or a
shortcoming in Perl is actually a feature in CLOS.
In the C++ View of the World you should be able to derive from a class
without examining the bases - especially the indirect bases. I thought
it made sense for years.
Until I realized that the 'miraculous reuse by accident' is a complete
lure. Which did a lot of harm to the reputation of OO. I now believe
that reuse is the consequence of ad-hoc design and cooperation between
the involved classes, that it has to be planned for and that it has a
cost - typically two or three times the cost of a non-reusable
design. Someone even said that the word 'reuse' made it look too
simple and suggested using the word 'polybloodyhardreuse' instead g
Thus, regardless of the issue about field inheritance, I believe that
"you can't safely subclass a class, without examining it's source" (or
its documentation, which should spell out the existence and purpose of
each field).
Also, consider what happens in presence of multiple inheritance,
particularly in the 'mixin' style. Typically you want to share a
single base sub-object even if a class is inherited more than once
(iow you want what C++ calls 'virtual inheritance'). Currently, in
Perl you get that by default. If you introduce scoped fields (by
default), you'll also have to introduce two kinds of inheritance:
shared and repeated.
I'm more in favor of a mechanism that makes it easy to build field
names from the package name, for those rare cases where you want
scoped fields. There were discussions about this a couple of years ago
on p5p. For example:
package Foo;
sub new
{
bless { "${CURRENT_PACKAGE}name" = 'Simpson' ...
}
...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)
--
Jean-Louis Leroy
http://users.skynet.be/jll
Re: RFC 50 (v1) BiDirectional Support in PERL
On Sun, Aug 06, 2000 at 09:36:12PM -0400, Ken Fox wrote: Perl6 RFC Librarian wrote: BiDirectional Support in PERL I know nothing about bi-directional output. It doesn't seem like Perl has any assumption of left-to-right at all. What's the difference between right-to-left support in Perl and just editing/using Perl in an xterm that does right-to-left? - Ken The main application of this is going to be CGI field, for the people who fill and submit forms containing RTL language and expects to receive the RTL output. I wrote a WWW mail program with hebrew support once. Pain in the ass to invent and reinvent functions for printing Hebrew correctly. Moreover, a lot of self-written reversing and replacing reduces the performance from what it would be if we just had it implemented in the core of Perl. -- Roman M. Parparov - NASA EOSDIS project node at TAU technical manager. Email: [EMAIL PROTECTED] http://www.komkon.org/~romm Phone/Fax: +972-(0)3-6405205 (work), +972-(0)54-629-884 (home) -- The economy depends about as much on economists as the weather does on weather forecasters. -- Jean-Paul Kauffmann
Re: RFC 49 (v1) Objects should have builtin string SCALA
On Sun, 6 Aug 2000 18:28:29 -0800, Michael Fowler wrote: print $pw; print scalar $pw; These resulting in a $pw-STRINGIFY or $pw-TO_STRING call is also confusing; neither are being used as strings. Oh yes they are. $^W = 1; my $x; print $x; This complains of a "use of uninitialized value". When does this happen? When the undef is converted to a string. $y = 2*3; print $y; Does this print a number, or a string? It prints the result of the calculation, a number, as a string. After this, the string value of $y, "6", will even be cached as a string inside $y. I could go on. Printing a list will convert every single list item into a string. This also clearly points out another reason why "turning into a scalar" and "turning into a string", or into a list of strings, is not the same thing. -- Bart.
Re: RFC 22 (v1) Builtin switch statement
On Sat, Aug 05, 2000 at 04:10:20AM +1000, Damian Conway wrote: If a switch is considered like a loop then next would be the same as 'break' in C, as would last and redo would repeat the switch. But a switch is not a loop. True, but in perl any block is considered to be a loop that executes only once. Long and bitter experience indicates that fallthrough is a poor default (but a good *option*). I guess it's what your used to. Graham.
Re: Deep copy
Dan Sugalski [EMAIL PROTECTED] writes: At 05:31 AM 8/7/00 +1000, Damian Conway wrote: Another one for my wish list: deep copying support built in. A devil inside me thinks this should be a new assignment operator. Damian? Sounds like this is up your alley. I want to do a sanity check before taking up RFC space. Regardless of how this looks, it has some pretty significant ramifications for the internals. What, for example, should happen if you deep-copy a DBI object attached to an Oracle database? I would say that encountering an "external component" such as a file handle during a clone() should either shalow copy the component or else throw an exception. That's cool. I can also see calling a package's CLONE sub if you're cloning something blessed into it. Presumably it'd get the original as a parameter and return the new thing, or something of the sort. With a UNIVERSAL::CLONE that does the Right Thing for a 'typical' object representation. (eg: blessed hash currently, but possibly something more efficient in Perl 6) -- Piers
Re: Deep copy
Lisp, which you might expect would have a 'deep copy' operator, doesn't have one. The Lisp folks have apparently thought about this very carefully, and decided that the semantics are unclear, and that the obvious options are all wrong; I've read a number of articles about this in the past. I don't remember all the details, unfortunately. But I think it's worth paying attention to prior art where there is some. This article http://world.std.com/~pitman/PS/EQUAL.html discusses this in some detail. I haven't thought about this in the context of Perl yet, so I'm not sure if all the reasons apply. Also if you do a Deja search in comp.lang.lisp for the phrase "deep copy", you'll find an extensive discussion of why it doesn't make sense, at least in Lisp. I'll also note the the same problems comes up when comparing for equality; if you want a deep copy operator, you should also want a deep compare oprator. But Lisp has not one but *five* equality comparison operators, and part of the proliferation is for the reason that the 'deepness' of the desired comparison varies from application to application. Perl has two equality comparison operators and people aready complain that that is too many. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote: On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote: Basically, you don't want to go anywhere near this mess; it eats people. I agree. I see two reasonable options to go with instead. One is to just use a binary flag that says use UTC or not; this is the simplest and most reliable to explain. The other is to allow a timezone offset; this doesn't deal with daylight savings time and historic time zone changes, but it provides enough power for most of what people want to do and if you want to deal with the rest you have to deal with time zone naming. I agree completely with Russ, and I would further state that I don't want this Cdate feature in the core. Dates, times, timezones, leap seconds, month and day names, localized formats, etc., are too complex. No one here has thought out the complexity enough to say "this is what Perl will support from now on". Currently, there isn't even an adequate (in my opinion) module on CPAN that gives dates a proper abstract interface. Time::Object may be okay as a lightweight localtime/strftime interface, but it does not support date, as opposed to time/date, arithmetic, or rather, it mis-supports it. Since we really don't understand dates here, I don't want us commiting to a certain interface without a `use' directive in the program. Distribute Time::Object as a standard module, but keep it a module, and don't force its quirks on people. Certainly, don't force the complex, quirky, and untested interface being developed here now on anyone without a long, patient discussion period. This makes an incredible amount of sense. We could even let the user specify a coderef to a sub that implements their own particular timezone oddities. (i.e. a sub to tell date() what the TZ offset is) Gross. Put it in a module. -John
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote: I think the concept's great, just that the notation is really hard to read, and doesn't necessarily scream "function" to me (especially since _ is from stat already). I don't see why you can't simply use _. From the context, you clearly see that it's not a filehandle. And if all filehandles will have a '$' prefix anyway, the filehandle _ won't even exist any more. -- Bart.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
On Sun, 06 Aug 2000 21:54:47 -0700, Nathan Wiger wrote: Seems to me that a leading _ is worse for this than ^ Whatever prefix you choose, it should NEVER EVER be a \w character. And the general rule, until now at least, is that only characters from the ASCII repertoire are acceptable for progamming language syntax. (I merely have reservations WRT variable names, using accented characters or something.) -- Bart.
Re: RFC 15 (v1) Stronger typing through tie.
Nick Ing-Simmons wrote: John Porter [EMAIL PROTECTED] writes: my integer $quux = 4; I believe that would have to be integer my $quux = 4; at least in perl5... Well Larry has been using my Dog $spot; for a while. O.k., I see that now; I was thinking 'integer', in this case, would be syntactically analogous to 'tie'. -- John Porter
MLC has its own sublist: WAS: Re: Recording what we decided *not* to do, and why
Please post further MLC remarks to the MLC sublist: [EMAIL PROTECTED] I can't guarentee that any MLC comments posted under a different subject, and on a different list will make it into the final Multiline Comments RFC! Not to mention that this specific argument is already addressed in the current RFC posted there. --Michael John Porter said: Glenn Linderman wrote: When using an inline comment, I want to spend my character budget mostly on the comment, and just enough on the delimiters to see it effectively. # magic here # would do quite nicely When reading a script, I'd like to be able to quickly distinguish the comments using my eyeballs and brain, without the need to involve my fingers and editor Bogus arguments both, at least wrt #...# vs qc Same number of characters overhead, same LACK of obviosity to the eyeball.
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Bart Lateur,
On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote:
If we've decided that chomp isn't going to return the clippings, would it not
seem prudent to make
while (chomp(ARGV))
work like
while (ARGV)
You mean, like, the -l command line switch? (see perlrun)
chomp() on input, append newlines on print (though $\).
Related, I suppose. Currently 'while (ARGV)' means 'while ($_ = ARGV)'.
I propose making 'while (chomp(ARGV))' mean
while (ARGV) {
chomp;
. . .
]
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
==
For a physicist mathematics is not just a tool by means of which phenomena
can be calculated, it is the main source of concepts and principles by means
of which new theories can be created.
-- Dyson, Freeman
==
Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
Whatever you do, don't use those timezone names. Is EST Eastern US time or Eastern Standard Time in Australia? The same abbreviation is used in both places. Naming of time zones is a *huge* rathole that you probably just don't want to crawl into. The short abbreviations are *not* standardized and are quite frequently ambiguous. There are three other prevelant time-zone naming schemes: the POSIX one (EST5EDT, for example) is completely insufficient to actually represent time zone variations as they occur in the real world, the "old Olson" found in most Unix operating systems these days with names like US/Pacific doesn't offer enough granularity, and the "new Olson" method (the best of the lot) uses names that most people don't know (America/Los_Angeles for US Pacific for example). Basically, you don't want to go anywhere near this mess; it eats people. Heartily agreed. Having just parsed through several hundreds of megabytes of mailing list archives and having reported to Graham on which various date formats Date::Parse chokes on or returns zero from, I can say with some certainty that one should stay away from timezone names if at all possible. There are many unambiguous/nonstandard/unknown timezone names out there. I see two reasonable options to go with instead. One is to just use a binary flag that says use UTC or not; this is the simplest and most reliable to explain. The other is to allow a timezone offset; this doesn't deal with daylight savings time and historic time zone changes, but it provides enough power for most of what people want to do and if you want to deal with the rest you have to deal with time zone naming. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
On Mon, Aug 07, 2000 at 02:53:17PM +0200, Bart Lateur wrote: On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote: I think the concept's great, just that the notation is really hard to read, and doesn't necessarily scream "function" to me (especially since _ is from stat already). I don't see why you can't simply use _. From the context, you clearly see that it's not a filehandle. And if all filehandles will have a '$' prefix anyway, the filehandle _ won't even exist any more. Except that we still have positional and/or named parameters. I guess _, _1, _2, _foo, _bar could still work though. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 23 (v1) Higher order functions
Ken Fox wrote:
I think we need a curry context and that all curries must be surrounded
by parens.
.
sub traverse ($_);
my $sum = 0;
$root-traverse(($sum += __));
I think parens may be problematic, since nested lists flatten.
Maybe curlies could be overloaded yet again?
$root-traverse({$sum += __});
That has mnemonic value, since it looks kinda like an anonymous sub...
--
John Porter
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
Jeremy Howard wrote:
Yes, I change my mind sounds of gears clicking I like the '^' prefix
too. The difficulty of reading __ would be a pain.
But what happens here?
/^__foo/
Or here?
/^{__}foo/
Is the latter sufficiently unambiguous?
--
John Porter
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
Nathan Wiger wrote: Yeah, I personally can read this much clearer. Peter also mentions that __ is hard to distinguish from _, unless they're right next to each other, and I think this is a very valid point. This biggest problem with '__', imho, is that '_' is a valid identifier character. '__' is already a valid package name, or sub name, for examples. -- John Porter
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
Has anyone suggested '*'? Since its use for typeglobs is (repsumably) going away, it's available (right?). It the "wildcard" mnemonic value is consistent with "placeholder". -- John Porter
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Jeremy Howard wrote: Yes, they're not identical. What I mean of course is: (..-1) == reverse(map -__ (1..)); WHAT? So the semantics of .. are magically different in the context of (..$n) so as to produce numbers in descending order? I don't think so. -- John Porter
Re: RFC 53 (v10) Built-ins: Merge and generalize Cindex
Perl6 RFC Librarian [EMAIL PROTECTED] writes: =head1 DESCRIPTION At present Cindex only returns the index of the first occurrence of a specified substring. It is proposed that Cindex take a fourth parameter telling it which occurrence of a specified substring to locate: $first = index $string, $substring, 0, 1; # first occurrence $first = index $string, $substring, 0, 2; # second occurrence $first = index $string, $substring, 0, 3; # third occurrence If omitted, this fourth parameter would default to 1, thus preversing the current behaviour. The Crindex function would be unnecessary, being replaced by: $last = index $string, $substring, -1, -1;# last occurence Err... shouldn't that be $last = index $string, $substring, 0, -1 # last occurrence $first = index $string, $substring, -1, -1 # first occurrence found # in a perverse way Or am I seeing double negatives where I shouldn't? -- Piers
Re: Different points of view, a little perspective.
At 11:40 AM 8/7/00 -0400, Michael Mathews wrote: In the MLC discussion I have read many comments about how various "C-style" features would be easier for people to learn, remember, and use. In fact the MLC discussion itself was inspired by a desire to make Perl more C-like (actually Java-like) in how it handles comments. Is this a worthwhile argument, even on its own? Perl is one of the very few languages geared towards a conceptual model which is essentially people. Pretty much all the other languages I can think of target a conceptual model where a person isn't central. That's something I don't think perl should lose. Becoming more C-like (or Lisp-like, or APL-like, or Prolog-like, or...) is moving in the wrong direction. Snagging things they do, sure. Just not the way they do it, unless that way maps well to the way that normal human beings (and let's face it, that does *not* target your average programmer dead-on) think of things. Human brains work very differently from computer brains. At this point we no longer need to cater to the computer--we have the power and the technology to make people the central focus and still perform well. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Deep copy
$want_deep_copy++; $want_deep_equal++; From: Mark-Jason Dominus [mailto:[EMAIL PROTECTED]] Lisp, which you might expect would have a 'deep copy' operator, doesn't have one. The Lisp folks have apparently thought about this very carefully, and decided that the semantics are unclear, and that the obvious options are all wrong; I've read a number of articles about this in the past. I should start by stating that I'm ignorant of Perl's internals, and a great deal of other knowledge that most people on this list take for granted. So if I sound stupid, please give me the benefit of the doubt, and assume it is ignorance to be cured (until I prove otherwise). Correct me where I'm wrong. There's got to be lots of material to work with here ;) Assumptions: - Larry wants to cultivate ideas from C# C# has very few types... word4, word8, etc. and float4, float8, etc. C# more or less infers the type from what is pushed on the stack. - People in the Perl community are requesting the ability to add new types for mathematical or other reasons. Wouldn't discussion of deep copying be tied to whatever is determined to be the best course for handling extensible types and data structures? I get a little confused when trying to distinguish the type of data from the structure of data in Perl. My assumed truth: Perl's "types" are hidden away in scalars and automagically managed and taken for granted by Perl programmers like myself. Scalars are both the data and a singular structure for holding a unit of data. Arrays and hashes are data structures for holding scalars. Shouldn't the scalar be able to copy and perform casts and comparisons between different types of data under the scalar hood? 'a' != 'b' 'A' == 65; And shouldn't the data structures be responsible iterating through the scalars to perform shallow and deep copies and comparisons. -Where the difference is whether or not to look at the reference or what the reference points to. Is ignorance letting me see clarity where it is really dark, complex, and murky? Data types handle copy and comparison operators. Data structures handle navigating themselves both shallow and deep. Why are things like objects, code, file handles, etc not scalars? Shouldn't every fundamental data type be hidden away behind the benevolent scalar? Then if someone decides to add a new type, it is their responsibility to define their copy and comparison operators right. Perl has two equality comparison operators and people already complain that that is too many. Yes, but when you need to do a deep copy, and you aren't a Perl guru... you really start to wish someone would provide one for you. --I've got a half functional deep copy subroutine that does most of what I need it to do, but it's not elegant... I'd rather see a more elegant solution and a couple more obscure operators so that working with deeply nested data structures would be easier. Garrett
Re: RFC 55 (v1) Compilation: Remove requirement for fina
John Porter writes: Compilation: Remove requirement for final true value in require'd and do'ed files Do not. I use this feature. Is there any reason you couldn't use "die" instead? Nat
Re: RFC: Rename local() operator
Nathan Wiger [EMAIL PROTECTED] writes: But it isn't "here" that's the problem. If we just wanted to change the value "here", we could use my(). The problem is that local() changes the value for somewhere else as well as here. Well, as has been pointed out, special^Wlocalized variables are scoped in time, not space, so: now $/ = "\n"; Personally, I like this alot, actually. It emphasizes what's going on really well. And it's short! As for the "need a verb" argument, my() and our() aren't verbs either. $/ = "\n" now; feels more English somehow. Would almost certainly be a bugger for perl to parse though. As for the 'need a verb' argument, it doesn't apply here because the assignment is the verb. -- Piers
Re: RFC 55 (v1) Compilation: Remove requirement for fina
Nathan Torkington wrote: John Porter writes: Compilation: Remove requirement for final true value in require'd and do'ed files Do not. I use this feature. Is there any reason you couldn't use "die" instead? ??? Throw an exception in order to return a (0|'')-but-true value? -- John Porter
Re: Treating filehandles like strings
Just a quick tangential comment: it should be possible to specify the maximum number of characters that a readline() will do on a filehandle. I couldn't find this in IO::Handle which seems to be where the user-defined line disciplines are inheriting their methods? Anyway, obvious application is to harden scripts against DoS attacks with endless inputs filling up the memory buffers while still allowing programmer to use . -- Peter Scott Pacific Systems Design Technologies
Re: RFC 55 (v1) Compilation: Remove requirement for fina
John Porter writes: Compilation: Remove requirement for final true value in require'd and do'ed files ??? Throw an exception in order to return a (0|'')-but-true value? If you want to indicate that there was an error in the code, why not die()? What am I missing? Nat
Re: RFC 53 (v10) Built-ins: Merge and generalize Cindex
I don't see the point. What makes you want to do this? And if you are changing it, why not make it return the list of matches in a list context? $last = (index $string, $substring)[-1] (These type of translations/idioms might be candidates for optimization.) chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL This RFC proposes that the Cindex and Crindex functions be merged PRL and generalized, by adding a fourth parameter to Cindex. PRL =head1 DESCRIPTION PRL At present Cindex only returns the index of the first occurrence of a PRL specified substring. It is proposed that Cindex take a fourth parameter PRL telling it which occurrence of a specified substring to locate: PRL $first = index $string, $substring, 0, 1; # first occurrence PRL $first = index $string, $substring, 0, 2; # second occurrence PRL $first = index $string, $substring, 0, 3; # third occurrence PRL If omitted, this fourth parameter would default to 1, thus preversing PRL the current behaviour. PRL The Crindex function would be unnecessary, being replaced by: PRL $last = index $string, $substring, -1, -1; # last occurence -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RE: Deep copy
There are a wide range of tricky problems associated with deep copy and deep compare. I like the idea, but circular references can make this problematic even without external things (filehandles, dirhandles, objects from non-perl sources) are thrown in. That needs to be taken into account when putting together the RFC for it, if someone even does. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 54 (v1) Operators: Polymorphic comparisons
This seems to be adding a special case. (I.e. only if _both_ are non-numeric will it switch to a cmp operation.) I currently fail to switch to 'eq' many times when I should, but the failure mode is obvious. Her the failure mode will be really strange. (And how does one tell if the string is numeric or not? eg. "35abc" == "n37c" ) Would modifying the waya number is converted to string be more satisfactory? I generally look at the 'cmp' amily as doing a lexical ordering. While the '=' as doing a numerical ordering. So I'm not sure that your generic insertion is generic enough. One still has to decide on the ordering. Enlighten me O' prolific one. chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL This RFC proposes that numeric comparison operators default to stringwise PRL comparison when both arguments are non-numeric strings. PRL =head1 DESCRIPTION PRL Currently the expression: PRL"cat" == "dog" PRL returns true. PRL It is proposed that if Ineither argument of a numeric comparison PRL operator can be converted to a number, rather than both being converted PRL to zero, the two operands should be compared using the equivalent PRL stringwise comparison operator. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 55 (v1) Compilation: Remove requirement for fina
Nathan Torkington [EMAIL PROTECTED] writes: John Porter writes: Compilation: Remove requirement for final true value in require'd and do'ed files Do not. I use this feature. Is there any reason you couldn't use "die" instead? Is there any reason that both couldn't be used at the same time? -- Piers
Re: Deep copy
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 10:07 AM 8/7/00 -0700, Peter Scott wrote: At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote: There are a wide range of tricky problems associated with deep copy and deep compare. I like the idea, but circular references can make this problematic even without external things (filehandles, dirhandles, objects from non-perl sources) are thrown in. That needs to be taken into account when putting together the RFC for it, if someone even does. I don't want it to go undocumented; I can write an RFC since I started the thread, or Damian can write it since he brought up clone() before that. I defer to Damian. I don't think it's impossible to do something useful, if we think sufficiently Perlish. DS That's fine. I'm not against it (I like it), I just want to know DS what needs to be done under the hood, and we need to document the DS pitfalls to folks that'll use it. the biggest pitfalls are circular structures. i see two opposing ideas here. the first is to allow deep copying but caveat coder. if you are doing circles, override with your own clone method. i know some here do circles a great deal and have to deal with it in DESTROY and other messy place. but the majority of perl data structures are plain trees which can be cloned easily. i also know that lisp tends to more circular stuff (since they HAVE to :) so they never did a generic deep copy. second, is we do a deep copy like someone mentions with Storable like semantics. it handles circles already. but again caveat coder as it can be a dangerous call to make. as for tied objects and databases, a hornets' nest awaits. 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
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
Me too, and I'm _not_ an astronomer. Tim Jenness wrote: Also, I would vote for a method to return the Julian date (yes I am an astronomer...) :-) -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 59 (v1) Proposal to utilize C* as the prefix t
If you're going to use a convention, rather than a syntax, then the current convention of all CAPS reserved to Perl is easier to understand, more pleasing to the eye, and backwards compatible. Good point. Maybe we're getting a little "fix-happy". :-) -Nate
Re: RFC 59 (v1) Proposal to utilize C* as the prefix t
At 10:29 AM 8/7/00 -0700, Nathan Wiger wrote:
With the proliferation of special subroutine names (BEGIN, END, INIT,
CHECK, etc.) the all capital subroutine names available to the
programmer has steadily shrunk. Rather than stealing subroutines from
the programmer, we should create a space just for Perl.
sub *BEGIN {
# do compile-time stuff
# Perl-special
}
I think this is a very valid point, but I don't think a special
character should be chewed up for this. In particular, I really don't
see typeglobs going away (they do some things you can't do otherwise).
Besides, subs already have a magic character - the word "sub".
Maybe just a convention like a leading underscore or two + CAPS?
sub _TIESCALAR {}
sub _FETCH {}
sub _STORE {}
sub _DESTROY {}
If you're going to use a convention, rather than a syntax, then the current
convention of all CAPS reserved to Perl is easier to understand, more
pleasing to the eye, and backwards compatible.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 55 (v1) Compilation: Remove requirement for fina
John Porter writes: But I admit this could be regarded as an edge case. Yeah, you could easily make this part of the module's interface. Removing the eval-to-true requirement would be one less arbitrary thing for people writing modules to do, and I'm very in favour of that. Nat
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
Also, I would vote for a method to return the Julian date (yes I am an astronomer...) :-) But surely not as a part of the core language? Exactly. In fact, I'm going to chop a lot of the original proposal out. It's too bloated for core. There's a lot of cool time/date stuff, but there's plenty of chance for external modules for that (including backwards localtime() compatibility). -Nate
Re: RFC 59 (v1) Proposal to utilize C* as the prefix t
At 12:55 PM 8/7/00 -0500, Jonathan Scott Duff wrote:
On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote:
At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
sub *BEGIN { ... }
sub *END{ ... }
sub *INIT { ... }
sub *AUTOLOAD { ... }
sub *TIESCALAR { ... }
sub *FETCH { ... }
Only half of those are subs.
What do you mean?
I meant that BEGIN, END, and INIT aren't declared as subs at present but
named blocks. I was surprised to discover that they're put in the symbol
table anyway though. But they're definitely in a different class,
syntactically if nothing else.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 54 (v1) Operators: Polymorphic comparisons
This RFC proposes that numeric comparison operators default to stringwise comparison when both arguments are non-numeric strings. The problem with this, is that we're removing orthogonality from the language. ROTFL. Do we want to say: $num1 == $num2 works $string1 == $string2 works $string1 eq $string2 works $num1 == non-decimal numeric literal works $num1 eq non-decimal numeric literal breaks? No, this last one still works. Damian
Re: RFC 52 (v1) List context return from filesystem func
Leon Brocard wrote: Perl6 RFC Librarian sent the following bits through the ether: affected files. I suggest that in a list context, they return the Inames of the Iunsuccessfully affected files. This seems the wrong way around to me. Surely it should instead return the name of the successfully affected files? Hm. You only want the names of the failures, becuase those are the ones you want to report / try remedial action for, etc. Now, Damian could of course extend his 'want' RFC to include a 'want-success' or 'want-failure' option :-) Hildo
Re: RFC 56 (v1) Optional 2nd argument to pop() and shift
proposed: @b = pop @a, $n; should this be equivalent to: @b = splice @a, -$n; # no longer a LIFO queue or : @b = reverse splice @a, -$n; # still a LIFO queue I guess it all depends on what you then do with @b, but you get my drift. This should be addressed, one way or another. -Aaron
Re: RFC 54 (v1) Operators: Polymorphic comparisons
Damian Conway wrote: This RFC proposes that numeric comparison operators default to stringwise comparison when both arguments are non-numeric strings. The problem with this, is that we're removing orthogonality from the language. ROTFL. But it's true. The semantics of == vs eq is currently very well defined and distinct. The proposal muddies the distinctions. The thing that allows you to LOL is precisely the thing which should motivate us to not reduce Perl's already low orthogonality quotient without very compelling reasons. -- John Porter
Re: ISA number
Peter Scott wrote: Have often wanted a way to tell whether a scalar was a number, and rolling a regex each time seemed wasteful given that Perl knew what it was anyway. So a user-friendly way to get at the SvIOK and SvNOK results would be great. The pedestrian way would be a builtin: isnum() or similar. But we have enough creativity here I'm sure we can come up with something far more obfusc^Wconcise :-) Agree here. I've seen people resort to DBI.pm's 'looks_like_number' or using tricks like ($a + 0 eq $a), but really this should be easier. Having said that, it doesn't need to live in the core - and even today it should be relatively easy to write an XS module for this. Hildo
Re: ISA number
Peter Scott wrote: Have often wanted a way to tell whether a scalar was a number, ... So a user-friendly way to get at the SvIOK and SvNOK results would be great. This is one of those rare proposals which can safely be assumed to be proposed, discussed, and accepted without dissent -- before the RFC is even issued! -- John Porter
Re: ISA number
At 12:27 PM 8/7/00 -0700, Peter Scott wrote: Have often wanted a way to tell whether a scalar was a number, and rolling a regex each time seemed wasteful given that Perl knew what it was anyway. So a user-friendly way to get at the SvIOK and SvNOK results would be great. The Sv?OK macros will likely go away in the new internals, or at least be different. It'd be better to figure out what you really want to know. Those macros tell you whether a scalar has already been changed to an integer, float, or string, rather than whether it can be an int, float, or string, for example. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Deep copy
At 01:27 PM 8/7/00 -0400, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 10:07 AM 8/7/00 -0700, Peter Scott wrote: At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote: There are a wide range of tricky problems associated with deep copy and deep compare. I like the idea, but circular references can make this problematic even without external things (filehandles, dirhandles, objects from non-perl sources) are thrown in. That needs to be taken into account when putting together the RFC for it, if someone even does. I don't want it to go undocumented; I can write an RFC since I started the thread, or Damian can write it since he brought up clone() before that. I defer to Damian. I don't think it's impossible to do something useful, if we think sufficiently Perlish. DS That's fine. I'm not against it (I like it), I just want to know DS what needs to be done under the hood, and we need to document the DS pitfalls to folks that'll use it. the biggest pitfalls are circular structures. i see two opposing ideas here. the first is to allow deep copying but caveat coder. if you are doing circles, override with your own clone method. i know some here do circles a great deal and have to deal with it in DESTROY and other messy place. but the majority of perl data structures are plain trees which can be cloned easily. i also know that lisp tends to more circular stuff (since they HAVE to :) so they never did a generic deep copy. Well, if we provide a primitive for this (a big if) I expect it can be piggy-backed onto the GC code somehow, which needs to do the same sorts of things. as for tied objects and databases, a hornets' nest awaits. No doubt. This is where the interesting work resides, which is why I'm all up for passing the buck to the mythical CLONE sub. :0 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 50 (v1) BiDirectional Support in PERL
On Mon, 7 Aug 2000 12:04:11 +0300, Roman M . Parparov wrote: I wrote a WWW mail program with hebrew support once. Pain in the ass to invent and reinvent functions for printing Hebrew correctly. Moreover, a lot of self-written reversing and replacing reduces the performance from what it would be if we just had it implemented in the core of Perl. That doesn't sound like it should be. The start of a sentence should come first, i.e. substr($_, 0, 1) should return the first character. Whether this should appear on the left or on the right of the screen, is not Perl's concern. Granted, I've heard of primitive output devices which a re blissfully unaware of the correct graphical output of such text strings, and which would print them from left to right anyway. But a silly patch that remedies the symptoms while ignoring the underlying false assumptions, does not seem right. What if you encounter a display device that correctly displays Hebrew text from right to left? -- Bart.
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
Andy Dougherty wrote: On Mon, 7 Aug 2000, Glenn Linderman wrote: Me too, and I'm _not_ an astronomer. Tim Jenness wrote: Also, I would vote for a method to return the Julian date (yes I am an astronomer...) :-) But surely not as a part of the core language? It isn't that hard/big; dates are an extremely useful type of value to manipulate; Julian dates are much easier to manipulate than year/month/day. That said, I really don't care if it is core, as long it is available in the standard distribution. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: Safer OO inheritance
I'm more in favor of a mechanism that makes it easy to build field
names from the package name, for those rare cases where you want
scoped fields. There were discussions about this a couple of years ago
on p5p. For example:
package Foo;
sub new { bless { "${CURRENT_PACKAGE}name" = 'Simpson' ... }
...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)
See the Tie::Securehash module for a variation on this theme.
Also note that I will be proposing something similar in my
general revamp of Perl OO (RFCs galore, probably next week).
Damian
Re: RFC 55 (v1) Compilation: Remove requirement for fina
On 7 Aug 2000 14:28:03 -, Perl6 RFC Librarian wrote: Compilation: Remove requirement for final true value in require'd and do'ed files Er... "do'ne" files? Anyway, There is at least one case where you need this true value: if the file accidently is empty (or equivalent). I've had that happen. A true value indicates that the file is indeed valid Perl. -- Bart.
Re: RFC 56 (v1) Optional 2nd argument to pop() and shift
Aaron J Mackey [EMAIL PROTECTED] writes: proposed: @b = pop @a, $n; That will change the behaviour of this perl5 code: foo(pop @a, "bar") If we do this then the code above need to be fixed by the perl5-perl6 filter. Regards, Gisle
Re: RFC 55 (v1) Compilation: Remove requirement for fina
Anyway, There is at least one case where you need this true value: if the file accidently is empty (or equivalent). I've had that happen. A true value indicates that the file is indeed valid Perl. So is an empty file! :-) Damian
RFC: Safe Signals
=head1 TITLE
Safe Signals
=head1 VERSION
Maintainer: Uri Guttman [EMAIL PROTECTED]
Date: 07 Aug 2000
Version: 1
Mailing List: perl6-language-flow
Number: TBD
=head1 ABSTRACT
This RFC describes how Perl6 can support safe signals with multiple
techniques.
=head1 DESCRIPTION
Perl5 suffers from its well know unsafe signal handling. It is due to
the asynchronous way signals are triggered at the level of C
code. A signal could be delivered in Perl while some critical operation
(e.g. malloc) is happening and all hell breaks loose. Signals have to be
delivered synchronously with respect Perl op code dispatching.
=head1 IMPLEMENTATION
There are multiple ways to support safe signals and they can all easily
be supported. Here are the most common ways and various techniques which
make handling signals easier.
=head2 In-line Code
If you have only a single linear thread of code and want safe signals,
you have to pay the penalty of checking for them in between Perl op
codes. This requires the Perl compiler to insert signal checking op at
regular intervals in the op tree. This can be done every N ops with N
being some special global value. The code to do the test can be done
in-line in the main dispatch loop and be very fast. The actual C handlers
will just be like the ones in the event loop and just bump counters and
set flags.
Enabling in-line testing for signals can also be a compile time option
so a selected section of of a thread could be where the test are
inserted.
Here is a possible pragma to enable this:
use signal in-line = 10 ;
Then you can just create callbacks for any signal as shown below.
=head2 Mailboxes
A mailbox is a combination of a semaphore and a queue/pipe. It is a
clean way to send messages between threads. A special mailbox for
signals can be created which can be tested and blocked upon. The data
read from the mailbox will be the signal name and any other info
attached to the signal. Any thread (including a single thread) can
synchornously test for signals under program control. This is how a
progrom would poll for signals.
=head2 Event Loops
Event loops support safe signals by delivering them synchronously with
the dispatch of other callbacks. Then the signal callback cannot collide
with any others. This is currently being done in Event.pm (and i think
Perl/Tk's event loop is similar here).
=head2 Threads
Threads can work with signals in two ways. First, one or more threads
can run event loops and their signal handlers are safe and can do work
or communicate with other threads. Second, any thread can block on the
special signal mailbox. When the signal is delivered, the blocked thread
can continue safely and can then do the work for that signal.
=head2 Callbacks
This pragma would use the same callback interface as all the new I/O
objects would. This consistancy of callback style in the language is a
major win here. Since someone mentioned any default Perl callback names
be in caps, will go with that here. Again the default method names
would be carefully chosen to be easy to remember and use,
e.g. SIGHUP_RECEIVED and SIGHUP_TIMEOUT would be the ones for the above
example if the callback value was an object or a class.
=head2 Timeouts
By using the general callback API, signals now can have builtin
timeouts. This simplifies some tasks which need to do work on a schedule
and also when you need it, e.g. checkpointing. If this were
triggered by SIGHUP, then it could be set to timeout every minute and
the callback would execute if there hasn't seen any HUPs in that period.
=head2 use signal pragma
I propose a pragma which would make creating signal callback more of a
top level operation and remove the need for the %SIG hash. The pragma
would be stackable so you could override a handler inside a code block.
It would be something like this:
# Here is a main line code callback with a sub ref and timeout
# the timeout will call the sub SIGHUP_TIMEOUT in this current package.
use signal name = 'SIGHUP', cb = \hup_handler, timeout = 3600 ;
sub hup_handler { print "They hupped me! Bastards!!" }
# Here is a class level callback with the default callback name
use signal name = 'SIGINT', cb = __PACKAGE__ ;
sub SIGINT_HANDLER { print "They killed me! Bastards!!" }
# Here is a object callback with the a custom callback name
my $foo = Bar-new() ;
use signal name = 'SIGCANCEL', cb = $foo, method = 'cancel_handler' ;
sub Bar::cancel_handler { print "They cancelled me! Bastards!!" }
=head1 IMPACT
People will stop bitching about perl not having safe signals.
=head1 UNKNOWNS
=head1 REFERENCES
Event.pm- XS based event loop module.
RFC #1 - Implementation of Threads in Perl
RFC #47 - Universal Asynch I/O (the moby one)
%SIG- perlvar
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
Re: DRAFT RFC: Enhanced Pack/Unpack
On Mon, 7 Aug 2000 13:52:09 -0400, John Porter wrote: Right, VAX is strictly little-endian. I.e. the address of a *word is the address of its least significant byte. (That's little-endian, isn't it?) Right. Why you people don't call it "Intel" vs. "Motorola", like the rest of the civilised world, I don't know. ;-) See the TIFF spec, for example. Er, in case you were in any doubt: Motorola (from the 68k processors) is BigEndian, Intel (x86) is LittleEndian. TIFF marks the files with either "MM" or "II". Sorry for the sidetracking. But IMO, it's not necessary for everybody to go and look this up independently. -- Bart.
Re: RFC 54 (v1) Operators: Polymorphic comparisons
"DC" == Damian Conway [EMAIL PROTECTED] writes:
I currently fail to switch to 'eq' many times when I should, but the
failure mode is obvious. Her the failure mode will be really strange.
DC I would claim that the failure mode is not obvious: "dog"=="cat" is true
Sure it is. I pass a large amount of data and _everything_ matches! Voila,
I messed up the test. Test looks okay. (If I was a newbie, '==' is broken.
Given my experience, I used the wrong test.)
DC I often need a generic comparison test (typically for equality of less-than),
DC and to get it one has to jump through hoops:
DC sub generic_eq {
DC my $failed;
DC local SIG{__WARN__} = { $failed = 1 };
DC return $_[0] eq $_[1] || $_[0]==$_[1] !$failed;
DC }
DC I want generic equality to DWIM. I.e. are these the same (for some
DC reasonable value of "same").
DC And "dog"=="cat" is not a reasonable value of "same".
Agreed. But ... one of the side effects of the '==' comparison is that
it coerces the two sides into being numbers. This has effects (not nice
ones) on future usages of the value. (Think '' and '|'.)
Are you proposing that usage of numeric comparisons _will not_ change
the 'type' of the arguments?
(This should be an internals issue, but in perl5 it is a user visible
effect. RFC anyone?)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 22 (v1) Builtin switch statement
On 4 Aug 2000 14:59:06 -, Perl6 RFC Librarian wrote:
%special = ( woohoo = 1, d'oh = 1 );
while () {
switch ($_) {
case (%special) { print "homer\n"; last } # if
$special{$_}
Hold it. Is that
if($special{$_}) { ...
or
if(defined $special{$_}) { ...
or
if (exists special{$_}) { ...
From a purist point of view, [3] makes the most sense. [1] may be more
practical, in a lot of cases. [2] is somewhere in between the two, where
a user could provide exceptional cases, for which this is supposed to
fail. Er... something like that.
--
Bart.
Re: RFC 55 (v1) Compilation: Remove requirement for fina
Bart Lateur wrote: Anyway, There is at least one case where you need this true value: if the file accidently is empty (or equivalent). I've had that happen. A true value indicates that the file is indeed valid Perl. That is a "lie", of the sort that Randal might tell you in day 1 of his perl course. -- John Porter
Re: RFC 50 (v1) BiDirectional Support in PERL
You missed part of his missive. He mentioned two different encodings. Logical and Visual. I'm not clear which is which. One orders the characters so that the first char is first. The other reorders the characters to correctly display on a device that can not understand rtl text. chaim "BL" == Bart Lateur [EMAIL PROTECTED] writes: BL On Mon, 7 Aug 2000 12:04:11 +0300, Roman M . Parparov wrote: I wrote a WWW mail program with hebrew support once. Pain in the ass to invent and reinvent functions for printing Hebrew correctly. Moreover, a lot of self-written reversing and replacing reduces the performance from what it would be if we just had it implemented in the core of Perl. BL That doesn't sound like it should be. The start of a sentence should BL come first, i.e. substr($_, 0, 1) should return the first character. BL Whether this should appear on the left or on the right of the screen, is BL not Perl's concern. BL Granted, I've heard of primitive output devices which a re blissfully BL unaware of the correct graphical output of such text strings, and which BL would print them from left to right anyway. But a silly patch that BL remedies the symptoms while ignoring the underlying false assumptions, BL does not seem right. BL What if you encounter a display device that correctly displays Hebrew BL text from right to left? BL -- BL Bart. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 50 (v1) BiDirectional Support in PERL
On 07 Aug 2000 17:27:55 -0400, Chaim Frenkel wrote: He mentioned two different encodings. Logical and Visual. I'm not clear which is which. One orders the characters so that the first char is first. The other reorders the characters to correctly display on a device that can not understand rtl text. I gathered that much. I've known ofthis trick being used for inputting RtL text into non-RtL savvy word processors. It's just that, in his application area, CGI, that the browser just might display it as RtL regardless of what he expected. It sounds like a hack. Should Perl support such hacks in the core? Is this sofisticated enough, or do we need something more low-level? $ltr = join '', reverse split /($sequence|.)/, $rtl; -- Bart.
Re: RFC 58 (v1) Cchomp() changes.
On 7 Aug 2000 16:06:44 -, Perl6 RFC Librarian wrote:
This RFC contains two proposed changes. First, as it is common to want to
removed newlines upon reading a file,
while (chomp(FILEHANDLE)) {
. . .
}
should become the equivalent of
while (FILEHANDLE) {
chomp;
. . .
}
...
Cchomp() called in a scalar context would leave its argument variable
untouched and instead return a Cchomp()ed version of that variable's
contents.
These two contradict each other. If the latter is realized, the while
loop of the former ought to be exited at the first empty line, or where
it contains just a zero (and an optional newline).
--
Bart.
Re: RFC 58 (v1) Cchomp() changes.
Thus it was written in the epistle of Bart Lateur,
On 7 Aug 2000 16:06:44 -, Perl6 RFC Librarian wrote:
This RFC contains two proposed changes. First, as it is common to want to
removed newlines upon reading a file,
while (chomp(FILEHANDLE)) {
. . .
}
should become the equivalent of
while (FILEHANDLE) {
chomp;
. . .
}
...
Cchomp() called in a scalar context would leave its argument variable
untouched and instead return a Cchomp()ed version of that variable's
contents.
These two contradict each other. If the latter is realized, the while
loop of the former ought to be exited at the first empty line, or where
it contains just a zero (and an optional newline).
I guess that's not yet clear to me. After all, as I had pointed out to me,
while(FILE)
means
while (defined($_ = FILE))
not
while ($_ = FILE)
even if the chomp() is handed an empty line, it will return a defined value.
Only at the point at which FILE returns undef will the while cease.
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
==
How can it be that mathematics, being after all a product of human thought
independent of experience, is so admirably adapted to the objects of
reality?
-- Einstein, Albert (1879-1955)
==
Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC 59 (v1) Proposal to utilize C* as the prefix t
At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: I meant that BEGIN, END, and INIT aren't declared as subs at present but named blocks. I was surprised to discover that they're put in the symbol table anyway though. Check the docs again. [snip] Four special subroutines act as package constructors and destructors. These are the `BEGIN', `CHECK', `INIT', and `END' routines. The `sub' is optional for these routines. Drat. I propose making it non-optional for P6. ETOOMANYSPECIALCASES. Any objections? -- Peter Scott Pacific Systems Design Technologies
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
John Porter wrote: Has anyone suggested '*'? Since its use for typeglobs is (repsumably) going away, it's available (right?). It the "wildcard" mnemonic value is consistent with "placeholder". Yes, it's been suggested, but we might be too late on that one--another RFC suggests reserving '*' for reserved perl identifiers. Maybe we don't have to resolve this in the RFC--since the choice of prefix depends on a number of other design decisions. Could we use one consistant prefix in the examples, and point out in the implementation that other prefixes are possible. eg: - ^: Our preferred option, but need to ensure that ambiguity in regexps is avoided - *: Next best, if not used to signify perl reserved identifiers - _: Next best option Is the regexp issue the only problem for '^'? If so, isn't this an issue for any prefix? Presumably the placeholder identifier should be 'special' under the same conditions as '$', when in a regexp...
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
At 08:19 AM 8/8/00 +1000, Jeremy Howard wrote: John Porter wrote: Has anyone suggested '*'? Since its use for typeglobs is (repsumably) going away, it's available (right?). It the "wildcard" mnemonic value is consistent with "placeholder". Yes, it's been suggested, but we might be too late on that one--another RFC suggests reserving '*' for reserved perl identifiers. Lord no - there's nothing wrong with contradictory RFCs. These are just ideas, we're not making the decisions here. -- Peter Scott Pacific Systems Design Technologies
Re: Safer OO inheritance
On Tue, Aug 08, 2000 at 06:22:03AM +1000, Damian Conway wrote: I'm more in favor of a mechanism that makes it easy to build field names from the package name, for those rare cases where you want scoped fields. [snip] See the Tie::Securehash module for a variation on this theme. Also note that I will be proposing something similar in my general revamp of Perl OO (RFCs galore, probably next week). Which is exactly what I thought of when I saw the original message. If tying is sped up, Tie::SecureHash could become far more viable for production code. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: Safer OO inheritance
On Mon, Aug 07, 2000 at 01:57:14PM +0200, Jean-Louis Leroy wrote:
package Foo;
sub new
{
bless { "${CURRENT_PACKAGE}name" = 'Simpson' ...
}
...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)
Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__? Is there a
reason to prefer it? I understand it can be interpolated, making it easier
to use within a string, but weigh that against adding yet another special
variable, for a value that's already available otherwise.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 55 (v1) Compilation: Remove requirement for fina
On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote: A true value indicates that the file is indeed valid Perl. So is an empty file! :-) That is precisely the problem. You won't get a syntax error if this happens. Now, bringing in the million monkeys typing, again: the chances of getting a corrupt file that yet is valid Perl source file, is *far* greater, if empty files are allowed as well. Empty files won't return a true value. Say you accidently erase the contents of some module file. The requirement of it returning a true value will immediately warn you where things went wrong. So require and do issue a warning if they require or do an empty file. Better that than meaningless 1;'s at the end of every module. Damian
RE: RFC 59 (v1) Proposal to utilize C* as the prefix t
From: Peter Scott [mailto:[EMAIL PROTECTED]] At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: Check the docs again. [snip] Four special subroutines act as package constructors and destructors. These are the `BEGIN', `CHECK', `INIT', and `END' routines. The `sub' is optional for these routines. Drat. I propose making it non-optional for P6. ETOOMANYSPECIALCASES. Any objections? Yeah, I have to object on the basis that it seems Perlish (and perlish, as far and I get that) to me for me to be able to skip a word here and there where what's happening (ie, I'm creating a set of instructions, or subrutine.) -Corwin
Re: RFC 53 (v10) Built-ins: Merge and generalize Cindex
On Mon, 07 Aug 2000, Damian Conway wrote: $last = index $string, $substring, -1, -1;# last occurence Err... shouldn't that be $last = index $string, $substring, 0, -1 # last occurrence $first = index $string, $substring, -1, -1 # first occurrence found # in a perverse way Or am I seeing double negatives where I shouldn't? No. You're missing the fact that the third argument of rindex specifies the last character at which the match can be found (as opposed to index's third arg which specifies the *first* character from which to search) Is this one of those "Magic Eye" things where if you stare at it long enough, you'll eventually see the picture? .. .. .. .. .. .. Oh, now I get it. I understand now, but that certainly wasn't my first, second, or third interpretation of it. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Safer OO inheritance
2000-08-07-19:22:59 Michael Fowler:
Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__?
I'm guessing no, unless I've misunderstood something from the
preceeding discussion.
Is there a reason to prefer it?
I suppose some folks who want to do a truly stunningly huge amount
of this stuff might want to get an variable they can slightly more
easily interpolate, and don't want to just
my $CURRENT_PACKAGE = __PACKAGE__;
right after the "package" declaration. But you'd really have to be
doing a _huge_ amount to pay for the extra
documentation/implementation complexity.
I understand it can be interpolated, making it easier to use
within a string, but weigh that against adding yet another special
variable, for a value that's already available otherwise.
and if you don't want to do a gigantic amount of it, stuff like
bless { "@{[__PACKAGE__]}stuff" = 0, ... }, $self;
isn't too bad.
-Bennett
PGP signature
Re: RFC 55 (v1) Compilation: Remove requirement for fina
On Mon, 07 Aug 2000, iain truskett wrote: Who here has actually used something other than a constant '1' in a package? If so, why? (Possibly cite the code.) I have. I've used 34. (Just 'cause I like the number.) I've also used the filename before. (I wanted to watch the order of various modules being used, and was testing out my implicit print hack. :-) Neither case should be considered justification for any decision being made. I tend to be a fringe programmer, and do things just because I can. -- Bryan C. Warnock ([EMAIL PROTECTED])
RFC: println()
I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; instead of print "$textvar\n"; Ever so much easier to read and write, prints the arg and appends \n. Thank-You for consideration, great ideas I'm seeing here! -Ed Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: RFC 20 (v1) Overloadable and ||
expr1 expr2
...and detects that the LJ is overloaded, it could replace it with:
user_defined_and( sub { $expr1 }, sub { $expr2 } )
Along the same line it would be useful to be able to overload the "truth
operator" (bad word, I'm sorry). It's great to be able to do:
if ($var1 $var2)...
But if you also want to do:
if ($var1)...
It should be the same as:
if (user_defined_truth($var1))...
It's a natural extension and prevents you from having to do stuff like:
if ($var1 $true)...
--Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
It shouldn't be a problem. *_ would then be a 'special' reserverd identifier. *_name could be a named placeholder. chaim "JH" == Jeremy Howard [EMAIL PROTECTED] writes: JH John Porter wrote: Has anyone suggested '*'? Since its use for typeglobs is (repsumably) going away, it's available (right?). It the "wildcard" mnemonic value is consistent with "placeholder". JH Yes, it's been suggested, but we might be too late on that one--another RFC JH suggests reserving '*' for reserved perl identifiers. JH - *: Next best, if not used to signify perl reserved identifiers -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC: println()
Too special purpose. I assume you don't do print "foo\nbar\gasp\n"; very often. chaim "EM" == Ed Mills [EMAIL PROTECTED] writes: EM I actually saw this in the newsgroups and thought it was a neat idea. What EM about EMprintln $textvar; EM instead of EMprint "$textvar\n"; EM Ever so much easier to read and write, prints the arg and appends \n. EM Thank-You for consideration, great ideas I'm seeing here! -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
So is this a consensus?:
It is proposed that Perl introduce a new prefix '^', which indicates a
placeholder. This can be used in any of the following ways:
- ^identifier: named placeholder
- ^_: anonymous placeholder
- ^0, ^1, ...: positional placeholder.
I think this sounds good - great, actually. It's really flexible.
As for the regexp issue, just to clarify there's only one ambiguous case
we need to work out that I can see:
/.*^foo/; # ok
/^^foo/;# ok
/^foo/; # ambiguous
We could undo the ambiguity like so:
/^{foo}/; # like ${foo} and @{foo} and %{foo}
In fact, this seems built-in if we follow the same var conventions. We
can make ^ bind to {} as tightly as we need.
-Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
As for the regexp issue, just to clarify there's only one ambiguous case
we need to work out that I can see:
/.*^foo/; # ok
But:/.*^foo/m; #ambiguous
We could undo the ambiguity like so:
/^{foo}/; # like ${foo} and @{foo} and %{foo}
In fact, this seems built-in if we follow the same var conventions. We
can make ^ bind to {} as tightly as we need.
That would be the right solution. And of course one could use the {} anywhere
necessary or desirable:
my $sin_deg = sin(180*^{_}/$pi);
Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
We could undo the ambiguity like so:
/^{foo}/; # like ${foo} and @{foo} and %{foo}
In fact, this seems built-in if we follow the same var conventions.
We
can make ^ bind to {} as tightly as we need.
That would be the right solution. And of course one could use the {}
anywhere
necessary or desirable:
my $sin_deg = sin(180*^{_}/$pi);
This is looking quite perlish now, isn't it? And this example shows why '*'
can get a bit nasty:
my $sin_deg = sin(180**{_}/$pi); # Pardon?
Of course the same is true for ^:
my $reverse_test = SOME_FLAGS ^ ^_;
but at least ^^ isn't an operator like ** is. Also, you don't see binary '^'
all that often.
Compared to the downside of '_' (__ is hard to read on paper, _identifier
looks like a private method call), the downside of '^' (potential confusion
because '^' is also a binary operator) seems pretty small. As for '*', well
personally I hate it:
- '*' means something else in perl 5
(confusing C programmers is one thing,
confusing perl 5 programmers is another!)
- '* *{_}' will be a common construct, and is very confusing.
So what if Damian's redraft uses '^', but mentions '_' as a fallback option?
And there's no argument about having anonymous, positional, and named
placeholders in the redraft...?
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
And there's no argument about having anonymous, positional, and named placeholders in the redraft...? There's *always* arguments! ;-) Personally, if we have positional placeholders I don't see the need for named ones too. But I'm willing to be convinced. Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
Damian Conway wrote: And there's no argument about having anonymous, positional, and named placeholders in the redraft...? There's *always* arguments! ;-) Although arguments from the RFC author are generally more compelling ;-) Personally, if we have positional placeholders I don't see the need for named ones too. But I'm willing to be convinced. Well I thought Ken Fox's earlier example was a good one: my $f = (^x ^max) ? ^x * ^scale : ^y * ^scale; has to be called $f($x, $max, $scale, $y) ... Seems better to just write $f as: my $f = (^2 ^1) ? ^2 * ^0 : ^3 * ^0; Alright, yeah, maybe not. That's total gibberish isn't it. ;) So how about taking the *original* $f and rebinding the order of all the arguments: my $f = $f(^2, ^0, ^1, ^3); And the two live together quite nicely, as I described earlier (sorry Damian, I don't think I cc'd you on the original): ... - ^identifier: named placeholder - ^_: anonymous placeholder - ^0, ^1, ...: positional placeholder. Although not necessarily a good idea, these can be mixed in a single higher-order function: $icky_func = ^test ? ^2 * ^_ : ^3 * ^_; First the positional placeholders are filled in (a higher numbered positional placeholder than the number of parameters results in a compile-time error). The anonymous and named placeholders fill in the missing places in the order in which they appear, from left to right. Penultimately, I think it fits better with what the user expects. There's a nice parallel with '$' as used for: - $identifier: named variable - $_: anonymous/default variable - $digit ...: positional variable from last regexp Finally, when we have named arguments to functions (which I know you're working on, creating higher order functions will look very much like creating normal functions. So, are you convinced yet?
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
Jeremy Howard wrote: Damian Conway wrote: Personally, if we have positional placeholders I don't see the need for named ones too. But I'm willing to be convinced. I'd agree to the contrapositive: if we have named placeholders, I don't see the need for positional ones too. But I'm willing to be convinced. The below, with positional only, is total gibberish, as Ken points out. Well I thought Ken Fox's earlier example was a good one: my $f = (^x ^max) ? ^x * ^scale : ^y * ^scale; has to be called $f($x, $max, $scale, $y) ... Seems better to just write $f as: my $f = (^2 ^1) ? ^2 * ^0 : ^3 * ^0; Alright, yeah, maybe not. That's total gibberish isn't it. ;) -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
I'd agree to the contrapositive: if we have named placeholders, I don't see the need for positional ones too. But I'm willing to be convinced. The below, with positional only, is total gibberish, as Ken points out. To most, probably, but I say let the user decide. Like Jeremy points out: There's a nice parallel with '$' as used for: - $identifier: named variable - $_: anonymous/default variable - $digit ...: positional variable from last exp With ^ used in the same way, we're giving them the same power with higher-order functions. TMTOWTDI! :-) -Nate
Re: Treating filehandles like strings
[Reply to perl6-language-io as this is an I/O related.] Michael Mathews wrote: Here's a thought. Wouldn't this be cool (see below)? The idea is that in Perl 6 you should be able to read from a file handle one character or one line at a time (just like you can in Perl 5) BUT if you just go ahead and use the filehandle, directly, in a scalar context then perl will read it in as a string most efficiently, and allow you to perform your rgex, or whatever without creating a temporary variable just to hold the contents of that file. This is what the angle brackets do currently, unless I misunderstand you. I don't like the no-operator syntax you propose, because it hides the file operation. I'd rather have a filehandle stringify to the filename instead. open FH, $filepath; ($found) = FH =~ /pattern/; print $found; open FH, $filepath; ($found) = FH =~ /pattern/; # or print FH =~ /pattern/; print $found; #or just print FH; print FH; #or, for example @things = split /delimiter/, FH; @things = split /delimiter/, FH; And how would s// work, I wonder? Hmmm... something to think about! Anyone one smarter than me (includes nearly all of you) have a thought on this? FH =~ s/pattern/replacement/; # dies in current Perl Perhaps this behaviour should be changed for files opened '+'? Jon __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Tim Jenness wrote: Is localtime() used often enough to justify being part of the language? You're kidding, right? We wouldn't have had all those script kiddies complaining about year 19100 bugs and month-being-off-by-one errors if localtime() wasn't being used all of the time, whether in CGI code or not. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: Recording what we decided *not* to do, and why
John Porter wrote: Glenn Linderman wrote: When using an inline comment, I want to spend my character budget mostly on the comment, and just enough on the delimiters to see it effectively. # magic here # would do quite nicely When reading a script, I'd like to be able to quickly distinguish the comments using my eyeballs and brain, without the need to involve my fingers and editor Bogus arguments both, at least wrt #...# vs qc Same number of characters overhead, same LACK of obviosity to the eyeball. We can agree on the same number of characters overhead. My comment regarding # ... # characters were intended to address comparisons with things like using "#token ... token" in an in-line fashion, not as comparison with "qc...". Regarding obviosity, # end-of-line comments already exist and the eyeball has become trained to consider them as comments... for many years of shell, make, hosts file, etc. usage, long before Perl, the eyeball has learned to pick out # to mean beginning of comment. # (or the like, any bracket character, or, with deference to the multitudes of C and Pascal programmers, even the "*" character, as in "#*...*#") is a simple extension to #, and, by use of a bracket character (or *), implies there will be an end. qc... clearly raises the expectation of bracketing, but builds on absolutely no semantics with respect to commenting. Rather, it builds on the semantics of quoting, so the eyeballs wouldn't detect it as a comment, and the brain would wonder what kind of quoting this should be. Eventually, no doubt, the brain would catch on, but it would always remain confusing to the eyeballs, as the "qc" sequence could so easily be found in other, non-comment situations. While the "#" character is legal to use for other syntactical purposes in Perl (any place that "any character" is permitted, for example, q#...#, the availability of so many other characters to fill that bill causes me to avoid using # in those situations. The only situation in which I use non-comment-introducing "#" characters in my scripts are within quoted strings, where the "#" is required to appear for the purpose of the script. This encourages the eyeballs to retain their "# as comment" scanning ability! -- 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
RFC 17 (v2) Organization and Rationalization of Perl
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Organization and Rationalization of Perl State Variables
=head1 VERSION
Maintainer: Steve Simmons [EMAIL PROTECTED]
Date: 3 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 17
CVSID: $Id: RFC17.pod,v 1.3 2000/08/07 18:32:04 scs Exp $
=head1 ABSTRACT
Perl currently contains a large number of state and status variables
with names that resemble line noise (henceforth called C$[linenoise]
variables).
Some of these are (or should be) deprecated, and the naming methods for
the rest are obscure. Since we are (potentially) adding, removing, and
changing the functionality of these variables with Perl6, we should seize the
opportunity to rationalize the names and organization of these variables
as well. These variables need to be made available with mnemonic names,
categorized by module, be capable of introspective use, and proper
preparation made for deprecation and translation.
=head1 DESCRIPTION
CPerl allows for the runtime examination and setting of a number of
variables. These existing C$[linenoise] variables are horrible names and
need cleanup, re-organization, and syntactic sugar. Different variables
have different problems, usually one or more of the following:
=over
=item *
unused (as far as we know)
=item *
useless, but still appear in older programs
=item *
duplicated by other features
=item *
standing in the way of advance because of backwards compatibility
=back
In the pre-RFC discussion of this issue, it was also pointed out
that these variables are hard to deprecate without nagging the crap
out of users running the programs. The proposed solution was
broadly applicable, and has been spun off into RFC 3.
The use of the CEnglish module is an attempt to solve the anti-mnemonic
features of these variables. A better solution is to do it right in
the first place, with a number of attendant wins:
=over
=item *
no need for Yet Another Module to be loaded
=item *
promotes code readability
=item *
probably promotes core Perl maintainability
=item *
grouping sets of variables together by function gives
the code writer strong hints as to variables that might
affect each other
=item *
should we move formats (or any similar current core functionality)
to a loadable module, this neatly encapsulates all the data with
a single referenced name
=item *
solves problems with C$[linenoise] variable proliferation
=item *
potentially promotes introspection - see below.
=back
In addition, many features which are now (re)set by other calls should
set appropriate state variables as well. Thus a Cperl script which
contains:
use strict foo;
might set a var C$PERL_STRICT{foo}, and so forth (this is probably
a poor example).
Credit where it is due: the idea of putting related values together into
an appropriately tagged hash is shamelessly ripped off from common Ctcl usage.
=head3 Caveat - Global State Variables Are Dangerous
Having the setting of simple variables modify the function of a
broad set of things is an inherently dangerous and inelegant way of
doing things. Mark-Jason Dominus [EMAIL PROTECTED] has proposed that
they simply be removed whenever possible. I tend to agree with his
arguement, and join in urging that the problems he addresses in message
C[EMAIL PROTECTED] be addressed by the core teams
working in the areas that use such variables. The thread started my
Mark-Jason in Cperl6-language has a good discussion of the issues.
Notwithstanding, should the core team continue to allow global
variables for some purposes, the names and categorization should
be improved.
=head2 Advantages and Non-Loses
=head3 Clean Backwards Compatibility
To promote backward compatibility, one could write a Cuse antiEnglish
module which would alias the old names to the new ones. That Would Be
Wrong, but someone will probably do it - so it may as well be us.
Obviously we cannot provide backwards compatibility for a variable
whose meaning has changed or which has vanished, but most of the
rest can be captured cleanly.
=head3 Promoting Removable Core Modules
It has been strongly proposed that `core Cperl' be broken down internally
into a number of modules such that one could build smaller or larger
custom perls. This feature would ease that work, and possibly set a
standard for how well-behaved non-core modules should implement such
things.
=head3 Provide Possible Guidelines To Core-able Modules
The discussion of removable core modules has strongly implied (sometimes
explicitly stated) that sites could take modules which are not currently
in the core and move them there. Having a standard which those modules
could follow for variable setting and exposure would be a major win.
=head2 Disadvantages
=head3 Backwards Compatibility
Existing Cperl code which makes use of C$[linenoise] variables
which had not changed meaning in Cperl6 will fail if (as proposed)
the
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Nathan Wiger wrote: Also, I would vote for a method to return the Julian date (yes I am an astronomer...) :-) But surely not as a part of the core language? Exactly. In fact, I'm going to chop a lot of the original proposal out. It's too bloated for core. There's a lot of cool time/date stuff, but there's plenty of chance for external modules for that (including backwards localtime() compatibility). -Nate Agreed. It was getting a bit out of hand (although in principal Julian date could be the internal format :-) ). What is the reason why any of this has to be in the core? Could all the date/time stuff be moved into a standard module? Is localtime() used often enough to justify being part of the language? -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
A plea to RFC authors
When writing RFCs that talk about the inclusion of "interesting" new features--things like coroutines, matrix math, bizarre regex theory (yes, I know that's redundant), curried (or garlic'd, or peppered) subs, for example--it would be helpful if there was a good reference in the references section of the RFC. It doesn't have to be on-line, books or periodicals are just fine, nor does it have to be included in the initial proposal, but it should be in the final one, and the earlier the better. A quick rule of thumb should be "If it's not convered in the Camel 3ed, it ought to have a reference". This'll help folks that might participate but have no idea what you're talking about, the people that need to judge whether it's reasonable and feasable, as well as the people that will have to write the code to implement the feature. Even if it's something that "most CS educated folks" ought to know (a category a number of us don't necessarily fall into), it's handy to know where to look to brush up on the details of the thing in question. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
exception and error RFCs
don't cc to language i have not seen any posted (on dev.perl.org) rfc's on exception handling or errors. i would like someone to take one or both on and post it to flow. there was some discussion in language on those subjects but the threads have petered out (or have been drowned :-). so let's see some proposals for a throw/catch typeof thing or a more universal way to propogate errors. i, of course wouldn't mind seeing some form of callbacks. i am in favor of dropping %SIG altogether. my signals rfc (should be done tonight) can be modified/copied to support error callbacks of various types including the warning and die ones we have now. 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
RFC 54 (v1) Operators: Polymorphic comparisons
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Operators: Polymorphic comparisons
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 7 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 54
=head1 ABSTRACT
This RFC proposes that numeric comparison operators default to stringwise
comparison when both arguments are non-numeric strings.
=head1 DESCRIPTION
Currently the expression:
"cat" == "dog"
returns true.
It is proposed that if Ineither argument of a numeric comparison
operator can be converted to a number, rather than both being converted
to zero, the two operands should be compared using the equivalent
stringwise comparison operator.
It is further proposed that the current warning:
Argument "%s" isn't numeric
be changed to:
Arguments of "%s" aren't numeric - using string comparison instead
=head1 RATIONALE
Perl has excellent support for generic programming, because of its dynamic
typing, generic data types, and interface polymorphism. Just about the only
place where that DWIM genericity breaks down is in comparisons.
It is difficult to construct many generic algorithms and data structures
in Perl, because there is no generic way to specify an ordering on
dynamically typed data. For example, one cannot simply code a
generic BST insertion method:
sub insert
{
my ($self, $key, $value) = @_;
if (!defined($self-{key}))
{
$self-{key} = $key;
return $self-{value} = $value;
}
my $compare = $key = $self-{key};
return $self-{value} = $value unless $compare;
$self-{$compare} = $self-new() unless $self-{$compare};
return $self-{$compare}-insert($key,$value);
}
This will work well for numeric keys, but fail miserably on most
string-based keys, because = will generally return 0 for most pairs of
strings.
The above code would work correctly however if = detected the string/string
comparison and automagically used cmp instead.
=head1 IMPLEMENTATION
Dammit, Jim, I'm a doctor, not an engineer!
=head1 REFERENCES
Chapter 12 of "Object Oriented Perl"
RFC 55 (v1) Compilation: Remove requirement for fina
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Compilation: Remove requirement for final true value in require'd and do'ed files =head1 VERSION Maintainer: Damian Conway [EMAIL PROTECTED] Date: 7 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 55 =head1 ABSTRACT This RFC proposes that files compiled via a Crequire or a Cdo no longer be required to end in a true value. =head1 DESCRIPTION It is proposed that the final value in a file that is compiled using Crequire or Cdo no longer be significant. Instead it is proposed that files that wish to fail during compilation should throw an exception. Furthermore, any valueless exception (i.e. thrown with a simple Cdie;) that propagates through a Crequire or Cdo should automatically take the appropriate message string: "require failed: file "%s" threw an exception" "do failed: file "%s" threw an exception" Note that exceptions with some value would be passed through unchanged, allowing a compiled file to signal exactly why it failed. =head1 IMPLEMENTATION Dammit, Jim, I'm a doctor, not an engineer!
RFC 56 (v1) Optional 2nd argument to pop() and shift
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Optional 2nd argument to pop() and shift() =head1 VERSION Maintainer: Jonathan Scott Duff [EMAIL PROTECTED] Date: 7 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 56 =head1 ABSTRACT The inverse operations to Cpop() and Cshift() both accept a LIST to "add" to an array, yet Cpop() and Cshift() only remove Bone element from an array. In the interest of symmetry and TMTOWTDI, Cpop() and Cshift should allow the programmer to remove multiple items from an array. =head1 DESCRIPTION The intent should be obvious, but I'll point it out anyway. =head2 pop The documentation for Perl 5.6.0 states that pop has one of two forms: Cpop ARRAY, or just Cpop. This RFC proposes that a third form be added to Cpop() =over 4 =item pop ARRAY, EXPR EXPR would be evaluated to determine the number of elements to remove from the end of ARRAY and that number would be removed and returned. Thus Cpop() would be a more natural inverse to Cpush() (If you can add multiple elements to an array with Cpush(), why can't you remove multiple elements from an array with Cpop?) =back This functionality can currently be accomplished with Csplice(), but it is non-obvious that Csplice() should be the routine to call and the method isn't at all intuitive. To "pop" the last $N items off of the end of an array using Csplice(), the call looks like this: splice @array, -$N; # remove the last $N items contrast to the more natural looking pop @array, $N; # remove the last $N items =head2 shift The semantics for Cshift() are similar to Cpop() except that it operates on the other end of the array. Cshift() also suffers from the inability to shift more than one element from the array. Just like Cpop(), the two forms of Cshift() are a Cshift ARRAY, and just plain Cshift. This RFC proposes that a third form be added: =over 4 =item shift ARRAY, EXPR EXPR would be evaluated to determine the number of elements to remove from the beginning of ARRAY and that number would be removed and returned. Thus, Cshift() would be a more natural inverse to Cunshift. (If you can add multiple elements to an array with Cunshift(), why can't you remove multiple elements with Cshift()?) =back As with Cpop() the proposed semantics can be accomplished with Csplice() and are just as un-intuitive: splice @array, 0, $N; # remove the first $N elements contrast to shift @array, $N; # remove the first $N elements =head2 Random examples @numbers = 1..10; $ten = pop @numbers;# still works @popped = pop @numbers, 3; # Take away 7, 8, 9 push @numbers, @popped; # Put 'em back @popped = pop @numbers, 0; # Nothing happens @popped = pop @numbers, 9; # And then there were none. @numbers = 1..10; @popped = pop @numbers, 100;# And then there were none but # @popped only has 10 things @numbers = 1..10; $one = shift @numbers; # still works @shifted = shift @numbers, 3; # Take away 2, 3, and 4 unshift @numbers, @shifted; # Put 'em back @shifted = shift @numbers, 0; # Nothing happens @shifted = shift @numbers, 9; # And then there were none. @numbers = 1..10; @shifted = shift @numbers, 100; # And then there were none but # @shifted only has 10 things =head1 IMPLEMENTATION I don't know the gory details other than it should be possible. However, there is one implementation detail that occurs to me: What should happen when the expression given to Cpop(), or Cshift() evaluates to a negative number? I see three options: 1) Nothing. We can only pop/shift positive amounts 2) Act as if the number were positive (i.e. abs(EXPR)) 3) Cpop() would then act as Cshift() and Cshift() would act as Cpop() The author of this RFC sees arguments for all three. =head1 REFERENCES The Perl 5.6.0 documentation Lperlfunc/pop Lperlfunc/shift Lperlfunc/splice
RFC 58 (v1) Cchomp() changes.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Cchomp() changes.
=head1 VERSION
Maintainer: Ted Ashton [EMAIL PROTECTED]
Date: 7 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 58
=head1 ABSTRACT
The current return value of Cchomp() is little-used and tends to confuse
those learning perl. Here is presented a change to Cchomp()'s return value
and to the Cwhile(EltFILEHANDLEEgt) construction.
=head1 DESCRIPTION
This RFC contains two proposed changes. First, as it is common to want to
removed newlines upon reading a file,
while (chomp(FILEHANDLE)) {
. . .
}
should become the equivalent of
while (FILEHANDLE) {
chomp;
. . .
}
or, to put it more explicitly,
while (defined($_ = FILEHANDLE)) {
chomp $_;
. . .
}
where the various equivalent constructions would, of course, work as expected.
Second, as it seems common for someone learning perl to expect
$without_newline = chomp($previous_form);
to put a copy of the text in C$previous_form, sans newline, into
C$without_newline while not modifying C$previous_form, Perl should
do just that.
Cchomp() called in void context would remove the newline
from the variable (or members of the list) upon which it was called.
Cchomp() called in a scalar context would leave its argument variable
untouched and instead return a Cchomp()ed version of that variable's
contents. Likewise and furthermore for other contexts.
=head1 IMPLEMENTATION
As I know little about perl5 internals and even less about perl6, I shall
simply present the following notes:
=over 4
=item *
This proposal does not speak to what should happen with Cchop().
=item *
The proposed demise of C$/ and stated determination that there will be no
default filehandle will have an effect on Cchomp(). After all, that's how
it determines which character to seek at the end of the line.
=back 4
=head1 REFERENCES
The Camel II, pp 53 and 149.
Re: RFC: println()
[Reply-To set to [EMAIL PROTECTED]] Ed Mills wrote: I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; instead of print "$textvar\n"; Ever so much easier to read and write, prints the arg and appends \n. You can currently get this behaviour with print if you set $\ = "\n". I expect perl 6 to look more like perl 5 than Pascal. Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: Language RFC Summary 4th August 2000
At 12:04 AM 8/7/00 +0200, Bart Lateur wrote: On Sun, 06 Aug 2000 01:38:13 -0400, Dan Sugalski wrote: Even in perl5 an XS module can do _anything at all_. It can't access data the lexer's already tossed out. That's where the current format format (so to speak) runs you into trouble. Only if you insist on the identical syntax as it has been until now. You can cock something together something with here-docs. Implementation can at least partly be based upon sprintf. You can fake it now, sure. But it makes embedding expressions in the format-replacement a pain, and complicates the code a bit. Besides, what formats let you do is nice, and quite easy. Rather than force people to jump through hoops so we can remove it, we should instead generalize what it does so everyone can use it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
