Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism
On Thu, Aug 24, 2000 at 03:37:59PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Omnibus Structured Exception/Error Handling Mechanism
Woohoo!
catch Alarm = { ... }
catch Alarm, Error = { ... }
catch $@ =~ /divide by 0/ = { ... }
The = here seems like useless syntax to me.
try { ... }
catch MatchThis = { ... }
catch MatchThat = { ... }
catch { ... } # everything else
finally { ... }
Let me tell you some semantics and syntax that I've thought of ...
they're remarkably similar to yours ;-)
try { ... } # For every one of these, we have
catch BAREWORD { ... } # zero or more catch clauses
catch METHOD{ ... }
catch LIST { ... }
catch EXPR { ... }
catch { ... }
finally { ... } # and exactly zero or one of these
If the target of a catch is a BAREWORD or a string, it is taken to be
a class name and act as if $@-isa(BAREWORD) or $@-isa(STRING) were
invoked. If the isa() is true, the block executes.
If catch is given a METHOD (subroutine), it's evaluated as if
$@-METHOD were executed (with whatever arguments). If no such method
exists in the exception hierarchy for the thrown exception, it's taken
to be a normal subroutine and just executed. If the METHOD or
subroutine evaluate to true, the block is executed. (To force Perl to
treat it as a subroutine in the current package, explicitly qualify
it. I expect this usage to be rare, but I could be wrong.)
If catch has a LIST, each element of the list is evaluated as above
and if *any* of them return true, the catch block executes.
Otherwise, any arbitrary expression can be evaluated for truthness.
And Ccatch { ... }, of course, catches any exception. And Cfinally
{ ... } is always executed no matter what.
Upon completion of a catch block, the exception is considered handled.
If the catch block contains Cthrow; the current exception is kept on
the stack for subsequent catch blocks to deal with. Quick example:
try { 23 / 0 } # throws Math::DivideByZero
catch Math::DivideByZero { ... throw; } # not handled
catch Math::DivideByZero { ... }# handled.
finally { ... } # end processing.
A Cthrow inside of one of the catch blocks simply pushes the
exception on the stack and subsequent catch blocks get a chance to
handle it. If none of the catch clauses handle the exception, it's
propigated to the next enclosing exception handler after the finally
block is executed.
If multiple statements are required to compute the value of the
EXPR, use this form: catch do { a; b } = { ... }
Or how about just this:
catch { a; b } { ... }
Yes, I realize some hoops may have to be jumped through to
distinguish these:
catch { ... } # all exceptions
{ ... } # random code, Oops!
catch { ... } { ... } # catch only if the first block is true
But that's what computers are for!
No, now that I think about it, requiring the Cdo is best:
catch do { ... } { ... }
But that = still seems superfluous to me.
The "try" is not for Perl's sake. It's for the developer's
sake. It says, watch out, some sort of non-local flow control
is going on here. It signals intent to deal with action at a
distance (unwinding semantics). It satisfies the first rule
listed under LMOTIVATION.
Hmm ... I wonder if there's a way we can tell builtins (like open)
that they are to throw exceptions if they appear in try blocks?
Syntax
The comma or = in the catch clause is required so the
expression can be parsed from the block, in the fashion
of Perl 5's Cmap expression, list;
You mean like this?
@doubles = map { $_*2 } @numbers;
I don't see a comma or = in there at all ;-)
Lexical Scope
The authors would prefer that try, catch, and finally blocks
share the same lexical scope.
A few of us random commentators agree with this as well.
my $cents = 2;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism
On Thu, Aug 24, 2000 at 10:47:45AM -0700, Peter Scott wrote:
But I initially wanted to do without the = ... unfortunately that would
require another keyword to handle the EXPR case and it didn't seem
worth it.
Not necessarily.
catch { EXPR } { ... } # probably not going to work though
catch (EXPR) { ... }# this will work
catch do { EXPR } { ... } # this will work
Um, granted, but if you're going to need additional syntax around your EXPR
to disambiguate it then = seems as good as any and it has that neat "this
thing causes this thing" interpretation.
Okay, I'm just registering my opinion that I don't like it. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Towards a reasonable unwinding flow-control semantics.
On Wed, Aug 16, 2000 at 11:49:03AM +0100, Graham Barr wrote:
if any of the catch or finally throws, it is caught by a
try {} block up the stack.
Keep It Simple
What he said.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Exceptions and Objects
On Sat, Aug 12, 2000 at 07:07:18AM -0600, Tony Olekshy wrote: I also submitted RFC 96, which tries to address the stuff that is needed for extending beyond builtins while maintaining a standard Perl OO implementation and seperating the exception handling stuff from the exception class. Rereading RFC 80, I realize that they are closer than I thought, each emphasising different aspects of the problem. I've read this thread with some interest and I'm puzzled by something. Why are "objects" and "exceptions" always mentioned in the same breath? Does one need objects to have exceptions? Could someone enlighten me or point me at relevant references? thanks, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 120 (v2) Implicit counter in for statements, possibly$#.
On Tue, Aug 29, 2000 at 05:51:44PM -0500, David L. Nicol wrote:
I'd like to see a last-container-key attribute included as
a possibilty; and that attribute called ":n" to match the
argument of integer functions in introductory algebra. This
approach gives us
for $a @some_list {
print "$a is located at position ${a:n}\n";
};
The only response I received after suggesting it was that the
attribute might be better called ":i" for index.
By tieing the count accessor to the particular variable, problems
with scope in nested loops quite disappear.
The attribute also becomes available in "lazy arrays" and other
functions trying to pass themselves off as arrays, syntactically.
Interesting. I must have missed this. I'm not wild about the syntax,
but I like the idea. If everything become objects under-the-hood,
then we could have:
for $a (@array) { print "$a is at $a-index\n"; }
No, I'm not wild about that either, but it's an idea.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: The distinction between do BLOCK while COND and EXPR while COND should go
On Thu, Aug 31, 2000 at 01:26:26PM -0500, Christopher J. Madsen wrote:
I too would like to see last, next, redo work with do loops.
*Only* do loops or do blocks in general? And what should they do?
do { ... last; ... }; # exit the block immediately
do { ... next; ... }; # equivalent to last?
do { ... redo; ... }; # equivalent to last?
These fall right in line with the proposal that the "do" be optional
since we can already do these:
{ ... last; ... }
{ ... next; ... }
{ ... redo; ... }
And what about continue blocks? We can attach them to bare blocks,
but not to do blocks? That's weird.
However, I really don't want to see 'return' become a kind of 'last'
for do{}. How would I return from a subroutine from within a do loop?
Indeed.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 14 (v2) Modify open() to support FileObjects and
On Wed, Aug 09, 2000 at 07:26:29PM +, Nick Ing-Simmons wrote: Graham Barr [EMAIL PROTECTED] writes: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: How about this? open '/etc/passwd'; # file OK open '/usr/local/bin/'; # directory (note the trailing '/') Portability, not all platforms use / Hmm. So that would be open 'file://etc/passwd'; open 'dir://usr/local/bin'; with the default open method being "file"? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Summary of I/O related RFCs
On Wed, Aug 09, 2000 at 06:37:07PM -0700, Jon Ericson wrote: =item 33 (v1): Eliminate bareword filehandles. (language) No discussion. Using "$fh = open()" accomplishes this. I think everyone is in agreement that bareword filehandles must go. =item 39 (v1): print operator No discussion of a proposal to spell "print(LIST)" as "LIST". I'll discuss it now--Ick! End of discussion. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 14 (v3) Modify open() to support FileObjects and
On Mon, Aug 14, 2000 at 03:01:54PM -0700, Nathan Wiger wrote:
or less verbose,
$fh = open "http://my.homepage.com";
This is still up in the air. I think this will probably end up doing a
GET via the http handler on the webpage specified. That seems the most
natural, since you'd probably want these to work the same:
open http "http://www.yahoo.com"; # GET
open "http://www.yahoo.com"; # GET also
Random thoughts:
open "http://www.perl.com";
open "http://www.perl.com?foo=barbaz=blat";
open "http://www.perl.com", %args;
open "http://www.perl.com", { mode = 'POST' }, %args;
Hmm. I think that "modes" should be made explicit rather than relying
on special characters fore or aft of the "filename". Especially since
the individual handlers get to decide how they want to treat that
filename.
I'd say any "filename" that starts with the usual open-special
characters should take the rest of the string as a literal filename on
the local system.
Which makes it consistent with these, which you'd assume would work the
same:
open "/var/log/mylog";
open "file:///var/log/mylog";
open "file:///var/log/mylog", { mode = 'APPEND' };
Here's a translation of the last http and the above file opens:
http-open("http://www.perl.com", { mode = 'POST' }, %args);
file-open("file:///var/log/mylog", { mode = 'APPEND' });
What do you think?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Treating filehandles like strings
On Tue, Aug 08, 2000 at 11:44:10PM +0200, Bart Lateur wrote:
On Tue, 8 Aug 2000 16:32:26 -0500, Jonathan Scott Duff wrote:
I sincerely hope you really mean "Let's make ``open() or die''
optional" Exceptions should be integrated into the language but Ye
Olde "returns undef on error" should still be available as well.
try { $fh = open("foo") } catch { die "Oops" } # pick your syntax
$fh = open("foo") or die "Oops";
You may hope all you want. But what I gathered, and what I liked a lot,
was the idea that:
use Fatal;
$fh = open("foo.txt");
would act pretty much as if you had written:
$fh = open("foo.txt") or die "Can't open file \"foo.txt\": $!";
Oh, that's fine too. I don't have to "use Fatal" (or however it's
spelt in its final form) if I don't want to. The "exception paradigm"
is often complicated for simple things. The "returns undef on error"
paradigm is often too simple for complex error conditions. I think we
should have both. Let the programmer choose.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 336 (v1) use strict 'objects': a new pragma for using Java-like objects in Perl
On Thu, Sep 28, 2000 at 09:05:52PM -, Perl6 RFC Librarian wrote: =head1 TITLE use strict 'objects': a new pragma for using Java-like objects in Perl =head2 protected Just take Conway's RFC 188 and do a s/private/protected/g :-) "protected" is a very loaded term. What you propose to call protected in Perl isn't the same as protected in C++. This will cause confusion. =head2 private Like Conway's private operator defined in RFC 188, but accessing an hash key or a method that has been marked as private from outside the defining package should result in a fatal error. What does this buy us? What is the benefit? =head2 static Methods not marked as such should return a fatal error if called directly on the class. Again, where's the benefit? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
On Mon, Aug 28, 2000 at 08:12:22AM -0700, Nathan Wiger wrote:
Jonathan Scott Duff wrote:
I think that Csubst is too syntactically close yet semantically far
from Csubstr that the evil demons of confusion will rear their ugly
heads.
I agree too, any suggestions are welcome. The fact that 'sub' and
'substr' are already taken makes this tough...
Well, if s/// stays around, I imagine that's what people will use, so
we could call the function form Csubstitute. Only those weirdos
using the function form would have to pay the syntactic penalty. ;-)
Given the above, why not make a bare Csubst do something equally
useful? Here are some ideas:
subst; # removes leading and trailing whitespace
I like this one alot.
Me too. I put down the others to give people brain-food mostly :-)
But again, this doesn't seem to make much sense in what I would think
would be its common use (using the spelled out version):
while () {
substitute; # What the hell am I substituting?
...
}
Similarly with match:
while () {
next unless match; # Er, match *what*?
...
}
Both leave me hanging. I can't read Perl in english like I'm used to.
I wonder what happens when people start typing
$new = subst s/old/new/i, $old;
They get a syntax error! :-)
Honestly, I don't think that's a big problem. People don't do this with
split() now. I think people will either use the "backwards compat" s///
form or the function form.
But they might *accidentally* use both. I'd prefer that Perl ... you
guessed it ... DWIM here. I.e.,
$new = substitute s/old/new/i, $old;
would be equivalent to
$new = substitute /old/new/i, $old;
With a warning if they're turned on. Same for match.
Hmm. Does using the function form still give the ability to pick
delimiters? And what does *this* mean:
@stuff = split match /foo/, $string;
?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: What's in a Regex (was RFC 145)
On Wed, Sep 06, 2000 at 03:37:55PM -0400, David Corbin wrote:
Question: Is there value in extending the regex/pattern engine to
support matching patterns in a list of foobars?
I can see this taking two forms (beyond the strings we have today).
One is matching number patterns (fibonaci, etc), and the other is
matching lists of objects. The goal here would be to leverage all the
GENERIC knowledge/power such as +, *, ? {x,y} [] | (?=) etc., and use
this power where the fundamental thingy being matched is not a
character.
We can already match patterns in numbers as they are autoconverted
into strings as needed. To match a pattern against an object, I
expect the same treatment from Perl. (i.e., the object's "to string"
method is called before the match)
But you said "lists" up there and that sparked an idea in me ... What
does
@a =~ /pattern/;
currently do? AFAICT, nothing useful. But it could be a syntactic
shorcut for a pattern matching grep()
i.e.,
@a = @b =~ /pattern/; # equivalent to ...
($a) = grep { /pattern/; } @b; # but stops on first match
and
@a = @b =~ /pattern/g; # equivalent to ...
@a = grep { /pattern/; } @b;
Also, it'd be nice if
@a =~ s/foo/bar/g;
did something similar.
Comments?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: is \1 vs $1 a necessary distinction?
On Wed, Sep 27, 2000 at 08:15:53AM -0700, Dave Storrs wrote: Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of the regex. Is there any reason not to standardize these down to one notation (i.e., eliminate one or the other)? \1 can be used on the LHS of a s/// whereas $1 there probably won't do what you expect. Also, \1, \2, \3 only takes you as far as \9 ;-) If $1 could be made to work properly on the LHS of s///, I'd vote for that being The Way. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
On Thu, Sep 28, 2000 at 08:57:39PM -, Perl6 RFC Librarian wrote:
${P1} means what $1 currently means (first match in last regex)
I'm sorry that I don't have anything more constructive to say than
"ick", but ... Ick.
Well, maybe I do. Forget $P1. If the user wanted $1 from the
previous RE, then they should have saved it somewhere. This would
eliminate the "major" RE-engine changes to make $P1 work. But it
would require that the p52p6 translator make some really smart
modifications.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default
On Tue, Aug 15, 2000 at 08:02:46PM -, Perl6 RFC Librarian wrote: =head1 TITLE Yet another lexical variable proposal: lexical variables made default without requiring strict 'vars' Am I correct that the only significant difference between this and RFC 6 is that RFC says we should have to Cuse strict 'vars'; to get lexicals by default and this one says we shouldn't have to? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 57 (v1) Subroutine prototypes and parameters
On Tue, Aug 08, 2000 at 10:14:53AM -0700, Nathan Wiger wrote:
Er, I thought we were talking about setting named parameters, not
default values.
sub foo ($name = 'Fred', $age = 32) { # defaults
# do stuff with $name and $age
}
foo('Barney', 31); # Positional assignment
foo($age:31, $name:'Betty');# Named assignment
foo($age:=31, $name:='Betty'); # Named assignment v2
Wow, I was actually looking at this backwards. Let me brain dump:
# Defaults
sub foo ($name ||= 'Fred', $age ||= 32) { ... }
Okay, why "||=" there rather than just "="? AFAIK, "sub foo ($a = 1)
{ ... }" doesn't do anything useful in perl now, so we can do with it
what we will in relative impunity.
foo($age = 31, $name = 'Betty'); # Named assignment
But that already has a meaning that I'd hesitate to take away from the
programmer.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 153 (v2) New pragma 'autoload' to load functions and modules on-demand
On Wed, Sep 20, 2000 at 04:15:13AM -, Perl6 RFC Librarian wrote: =head2 The Basics The new Cautoload pragma would rely on an Cautoload.conf file that was located in C@INC and looked something like this: What happens when there are multiple Cautoload.conf files in C@INC? A custom one could also be included in C@INC ahead of the system one so that a user could include their own definitions. By this I assume multiple Cautoload.confs are appended together? Later you say: Cautoload should always use the last one in the list, since this will be the most recent one if the person is not actively maintaining the file (i.e., just letting it be appended to automatically). If it always uses the "last one", then later Cautoload.confs need to be prepended to earlier ones for what you say about C@INC to make sense. Anyway, the semantics of multiple Cautoload.conf files needs nailing down. use autoload '/home/nwiger/perl/autoload.conf'; I'd prefer that this be the *only* usage. Or, something else ... The program could contain it's own autoload.conf information after an C__AUTOLOAD__ line (similar to C__END__ or C__DATA__). =head2 Extensions The Cautoload pragma could be extended in several ways: 1. If duplicate modules or methods are found, autoload should issue messages like: Always or on-demand (i.e. via use warnings)? =head1 MIGRATION None. This introduces new functionality. What you have under "Module Installation" I'd've put under migration if it is to be the expected scenario. =head2 Module Installation On installation, some part of the Perl module install driven by CMakeMaker would have to read the exported function list from a given module and append it to the Cautoload.conf file. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC: lexical variables made default
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: Anything one chooses potentially conflicts with the user's namespace, but probably save() or temp() would be better, or even savetemp() or tempsave() or scopetemp(). How about deliver() or preserve()? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC: lexical variables made default
On Wed, Aug 02, 2000 at 09:15:38AM -0600, Tom Christiansen wrote: On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: Anything one chooses potentially conflicts with the user's namespace, but probably save() or temp() would be better, or even savetemp() or tempsave() or scopetemp(). How about deliver() or preserve()? I can slightly grok the latter, but not the former. What are you thinking there? Ah, I was thinking of save() and how it could be deliverance. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC stuff
On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote: Deprecate localtime() and replace with I'm willing to take a first whack at this one (but only with lots of input from others). I'll help. Let's call the replacement gmt2date() for now. gmt2date() should at least (IMHO): * return undef on failure (whatever that means) * output 4 (or more) digit years * have some mechanism to say "I really want localtime" rather than GMT * allow for fractional seconds (as per Gisle Aas's higher time-resolution RFC) * have a well defined range of time for which it gives correct answers date2gmt() should at least (IMHO agian): * return undef on failure (whatever that means) * accept 4 (or more) digit years * have some mechanism to say "I just gave you the seconds in localtime" rather than GMT * have a way to specify whether or not it's arguments should be range checked (thus it can accept weird dates like the 77th day of January (julian days) and still give a correct GMT value if we so desire) * allow for fractional seconds (as per Gisle Aas's higher time-resolution RFC) * have a well defined range of time for which it gives correct answers This is just off the top of my head and aren't well thought out ... but that's what RFCs are for, no? :-) That Perl should stay Perl Do we need an RFC for this? Seems like this is more of a "guiding concept" that should be intergrated into everything. Just my opinion. Well, it can't hurt to have a document to look at every now and then to remind us what Perl should look/feel like. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC: Modify open() and opendir() to return handles
On Thu, Aug 03, 2000 at 06:57:27AM -0600, Tom Christiansen wrote: On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote: Modify open() and opendir() to return filehandle objects Here are some things that that will be a problem for: I did not see any that would be a problem. It's not as convenient. Are you saying that piped opens returning a "filehandle" object makes testing for failure more troublesome? If so, I have an evil proposal for you ... Let's make an "error" object (I hate to use that term) that's *always* false but has some state we can get at. This thing would encapsulate $!, $?, and friends. Modules (like DBI) could even add state, but it would still be false. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: wantarray() should be named wantlist() (was Re: date interface (was Re: perl6 requirements, on bootstrap))
On Thu, Aug 03, 2000 at 10:02:44AM -0400, Tad McClellan wrote:
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
If functions could distinguish between
'wantarray' and 'wanthahs' this would be easy to do.
Due to the recent "rename local()" and "can't return an array"
discussions here, we should also consider "rename wantarray()"
as well.
It should be named wantlist()
Well, perhaps we should rename it to whatdoyouwant() :-)
Or perhaps you prefer the shortened version, want()?
if(want eq 'hash') { return %hash }
elsif (want eq 'array') { return @{$hash{vector}} }
elsif (want eq 'scalar') { return $hash{vector]-[0] }
elsif (want eq 'handle') { return $hash{filehandle} }
/me patiently awaits all those RFCs (or are we calling them PCRs now,
and won't that confuse the biotechnologists?) from Damian Conway.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: wantarray() should be named wantlist() (was Re: date interface (was Re: perl6 requirements, on bootstrap))
On Thu, Aug 03, 2000 at 11:15:17AM -0400, Clayton Scott wrote:
Why not context()?
Sure, that works too. Although for want(), I can see this instead:
if (want 'hash') { return %hash } # rather than eq
and that reads better than
if (context hash) { return %hash }
Hmm.
want = 'hash'; # tell the world I want a hash?
want = 'Foo'; # tell the world I want a Foo?
sub foo : want(Foo,hash,Dog), need(Foo) {
# foo() wants a Foo, hash, and Dog in that order
# foo() needs a Foo (must have)
}
okay, I've gone tangential ...
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC: Rename local() operator
On Fri, Aug 04, 2000 at 01:37:09AM -0500, J. David Blackstone wrote: =head1 IMPLEMENTATION Csave If I had my druthers, save() would be it. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 28 (v1) Perl should stay Perl.
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =item Functional Programming PRL Just because Perl has a Cmap operator, this doesn't make it a PRL functional programming language. Perl has always been squarely PRL procedural, and so things like Creduce and Ccurry and other cookery PRL terms are somewhat out of place; they can be far more easily and PRL appropriately implemented as extension modules Ipost hoc. By all PRL means, let's generalise the problem, and make it easier to define your PRL own syntax, but let's not add the entirety of LISP and ML to the core. PRL The CS types may love it, but I'm a programmer and I don't. On Fri, Aug 04, 2000 at 02:50:39PM -0400, Chaim Frenkel wrote: I'm not quite buying into this. I'm with Chaim on this one. One of the things I *love* about perl is that it doesn't constrain me to a particular paradigm and moreover it almost naturally supports other paradigms (like functional programming). I'm always touting this aspect of Perl and often people from other backgrounds (scheme, lisp, Java, etc.) are surprised and delighted when perl lowers the barrier to their entry and understanding. That said, if perl starts looking more like lisp than perl, I'll be here to yell bloody murder! along with Simon :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 22 (v1) Builtin switch statement
On Sat, Aug 05, 2000 at 05:09:28AM +1000, Damian Conway wrote:
Not necessary.
switch ($val) {
case 3 { print "three"; goto odds }
case 4 { print "three"; goto evens }
And "goto" could be spelt "next" too? That would make sense to me,
but the semantics of "last odds" or "redo odds" escape me. Perhaps
"last odds" would me "evaluate the block labeled by odds, then exit
the switch" and "redo odds" would me "re-evaluate this case, then jump
to the block labelled odds".
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC: Rename local() operator
On Sat, Aug 05, 2000 at 12:04:30PM +0200, Bart Lateur wrote: On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote: Csave If I had my druthers, save() would be it. I'm against it. Why? Because it suggests that all it does is save the value for later retrieval. It does not: the value is cleared as well. It masks the previous global value, as if it didn't exist before. save $/ = "\n"; That doesn't quite say it, does it? You're right of course, but I don't know of any one word that concisely and succintly means "save the current value of this variable, clear it, and restore on exit of the current scope" More words: store() # put away for the duration of the scope tuck() # Now I lay me down to sleep hide() # I kinda like this one :-) shelve()# probably too loaded stow() # Just sit right back and you'll hear a tale ... bury() # Oh my god! They've killed Kenny! I've changed my mind; my personal favorite is now "hide" -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC: Filehandle type-defining punctuation
On Sat, Aug 05, 2000 at 08:53:58PM +, Nick Ing-Simmons wrote: You loose one little thing - you have a new scalar (the handle) with open $fh,$filename one can re-use an existing thing to which someone else may have a reference. (Not that that is useful very often.) Well perhaps that's what $fh = open $fh; does. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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 59 (v1) Proposal to utilize C* as the prefix t
On Tue, Aug 08, 2000 at 09:28:17AM +0100, Piers Cawley wrote: Peter Scott [EMAIL PROTECTED] writes: 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? But what happens if you want multiple BEGIN blocks? The same thing that happens now. As I understand it, perl compiles and executes the BEGIN block then detroys it so that you may have as many BEGIN blocks as you want and each time perl thinks it's the first one. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 59 (v1) Proposal to utilize C* as the prefix t
On Tue, Aug 08, 2000 at 09:27:24AM +0100, Piers Cawley wrote: Proposal to utilize C* as the prefix to magic subroutines I freely accept that this is not anything approaching a reasoned critique but: Yecch! That comment is as good as any :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Things to remove
On Tue, Aug 08, 2000 at 03:46:45PM +, Ed Mills wrote: As long as were culling, might want to consider removing chomp() and possibly chop(). The language provides other ways to accomplish those thru a simple regex, and if the "println" suggestion I made was "too specific" then certainly chomp() is as well. TMTOWTDI. chop() and chomp() should stay (IMHO). Your "println" suggestion has merit though. There's already a way to accomplish it via a command line switch (-l), but I guess what you're after is a language level method to turn automatic addition of newlines on and off. How about a new lexical pragma--newlines? use newlines; print "Hi"; # Automatically adds the newline no newlines; print "Hi"; # Does NOT automatically add the newline -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 23 Higher order functions
On Tue, Aug 08, 2000 at 01:27:48PM -0400, Andy Dougherty wrote: It strikes me that this is very fragile and limited (unless I misunderstand, which is quite possible). For one thing, it appears to only be useful if your subroutine uses each argument exactly once. If you need to use any of the arguments more than once, you can't use this notation. For example, you might want to check $_[3] to be sure $pi/$_[3] didn't end up dividing by zero. I don't see how to to that with the __ version. Further, if you find you need to revise the check function in a way that changes the order in which the arguments are used, but you don't want to replace all the calls to $check elsewhere in your code, I don't see how you can do that with the __ version. Yep, both very valid points. Thus somewhere buried within the thread of discussion following this RFC was proposed positional and/or named currying with _1, _2, _3 and/or _foo, _bar, _baz. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Things to remove
On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote:
I'm not sure if I'm the someone you meant, but if so, the proposal was to make
while (chomp(FH)) { ... }
work like
while (FH) { chomp; ... }
Oh. I think I'd prefer to see chomp() go away and be replaced by
something like this:
$fh = open "foo" or die;
$fh-auto_chomp = 1;# Insert some appropriate syntax
$fh-newline = "\n";# Insert some appropriate syntax
while ($fh) {
...
}
close $fh;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 58 (v1) Cchomp() changes.
On Tue, Aug 08, 2000 at 01:56:12PM -0400, Uri Guttman wrote: a couple of ideas. one, i proposed we keep a global $/ and $\ for default use by handles which haven't set their own. Rather than having global $/ and $\, each filehandle has their's defaulted to something reasonable. two, instead of tying the chomp the string and the stream it cam from (boy would that be easy to break), how about tying it to the handle itself? $fh = open( ); $fh-IRS( "\r\n" ) ; $fh-chomp( $foo ) ; now whether chomp works on the var or returns the chomped string is still an issue. since this chomp is an method, how about if we pass it a reference to the var, it works on the var. else it works on the string and returns it. How about $fh-chomp($string); modifies the string and returns the what it removed? This could be useful if "end of line" varies while reading from a single stream. As an aside: How do we get at the magic filehandle or its settings. Would we usurp $ARGV to be the object and $ARGV-filename to do what $ARGV currently does? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 58 (v1) Cchomp() changes.
On Tue, Aug 08, 2000 at 02:16:57PM -0400, Ted Ashton wrote:
I, for one, would like to know where the assumption came from that there would
be no default filehandle.
I believe Larry said he was probably going to axe it.
Is it necessary that instead of typing
print 'Hello World.';
we need now type
$STDOUT-print('Hello World.');
Is that not going the wrong direction?
Indeed it is. However, print() could be prototyped to take an
optional first argument that has a default value of $STDOUT (or
whatever we call it) Getting rid of default filehandles will make
this not work:
select($STDERR);# Perl 6 Error
print "Oops!"; # Always goes to STDOUT
but that can always be replaced with
print $STDERR "Oops!";
or even
local $STDOUT = $STDERR;
print "Oops!";
programmatically.
Of course we could define chomp() to have an optional first argument
that is the filehandle to do the chomping on too. These sorts of
decisions will have to be made on a per-subroutine basis rather than
having some global $/ that affects many different subroutines.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: default $/ (was Re: RFC: println())
On Tue, Aug 08, 2000 at 01:50:35PM -0400, Ted Ashton wrote: Hear, hear! Chomp (which I still consider a useful critter :-), needs a $/ sort of thing to know what to chomp and the lines it chomps may or may not have come from a given file. Chomping *is* useful, but it's a per-filehandle thingy. If the line it chomps isn't coming from a file, where does it come from? (s/file/any form of IO/ because that's what we're really talking about) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: default $/ (was Re: RFC: println())
On Tue, Aug 08, 2000 at 02:44:59PM -0400, Uri Guttman wrote: the key word besides global is default. this would be the value used by any new filehandle created. you can override that at anytime in that filehandle. otherwise the default value for $/ for new handles will be hardcoded in %CONFIG or something like that. the global aspect was meant to show it was the default for ALL new handles. i don't care if it is in $/ or some new place. Yes, yes, you are right ... I was suffering from perl 5 myopia. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 48 (v2) Objects should have builtin stringifying
On Tue, Aug 08, 2000 at 05:15:24PM -0400, John Porter wrote: Jonathan Scott Duff wrote: If we had a context coercion operator that was the opposite of want() we could do something like this: print context '*STRING', $val; # long-hand for print $val print context '*SCALAR', $val; # we're not in a string context print context 'MyClass', $val; # we're not in a string context We already have scalar(). We should also have string(), void(), etc. for the "intrinsic" contexts. And what about user-defined contexts? (my Dog $spot = some_func();) I think a context coercion operator would do just fine. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Tue, Aug 08, 2000 at 09:50:27PM +0100, Matt Sergeant wrote: All I can say to that is, ugh! I don't want to see Perl6 be so fundamentally different to perl5 that I have to translate every single script. I want some better stuff, but a new language is not what I'm looking for. All of your programs may need translating anyway. They just might be translated on-the-fly by perl6 and all you'd have to do is add a command line switch or add "use Perl5;" or maybe absolutely nothing at all. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Wed, Aug 09, 2000 at 10:10:29AM -0700, Nathan Wiger wrote: Agreed. General-purpose timezone support is scheduled for a swift and painless death in the next version of RFC 48. Only the local timezone and GMT will be included in the RFC, same as now. By "local timezone" do you mean that some sort of inspection happens to determine the local timezone and the date() intrinsically knows about it? What about daylight savings time? I presume the ability to specify an offset from GMT will be built in to date()? And I still think it would be a good idea to let the user somehow provide an anonymous sub to date() that will tell date() the proper offset from GMT for "localtime" if we're going to support that concept at all. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 80 (v1): Exception objects and classes for builtins
On Thu, Aug 10, 2000 at 05:11:17PM +0100, Graham Barr wrote:
I was more thinking of
eval {
# fragile code
}
else {# catch ALL exceptions
switch ($@) {
case __-isa('IO') { ... }
case __-isa('Socket') { ... }
else { ... }
}
}
continue {
# code always executed (ie finally)
}
I like it.
BTW, that switch could be written like this:
switch ($@-isa(^_)) {
case 'IO' { ... }
case 'Socket' { ... }
... # else code
}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 89 (v2) Controllable Data Typing
On Mon, Aug 14, 2000 at 01:46:55PM -0400, Lipscomb, Al wrote: While the implicit change works on most (if not all) situations it would be nice to have a way to control the conversion. Sounds like an RFC to me :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: =head1 TITLE Maintain internal time in Modified Julian (not epoch) How would this be stored? As a floating point number? What about sub-second accuracy? To get seconds you'd need about 5.15 decimal places (let's just call that 6) I think it should be stored as 2 numbers, the julian day and the seconds into that day. Also, I'd bet that most people only use time() in conjunction with one of the other date/time routines to get hours/minutes/formatted time/formatted date/whatever. Will these other date-ish routines have to be modified to understand mjdate() output? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 02:42:39PM -0400, Dan Sugalski wrote: At 01:36 PM 8/14/00 -0500, Jonathan Scott Duff wrote: On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: =head1 TITLE Maintain internal time in Modified Julian (not epoch) How would this be stored? As a floating point number? What about sub-second accuracy? To get seconds you'd need about 5.15 decimal places (let's just call that 6) I think it should be stored as 2 numbers, the julian day and the seconds into that day. How 'bout 100ns ticks from base date, stored in a 64-bit number? That should see us into Y30K, assuming the integer is signed... Sure, but does that mean that perl will support 64-bit ints on all platforms? I think automagic type promotion to/from bigints would be great but it would swamp anyone doing lots of date/time calculations. I'm just guessing that manipulating time values is much more common than arithmetic with large numbers. Or will we have special purpose stages in between able-to-use-native and need-to-use-something-bigger, one of which could be 64-bit? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 03:01:48PM -0400, Dan Sugalski wrote: I'm not sure anyone does that much in the way of time/date work that it'd make a difference. Besides, we're talking internal here--time() may still return Unix epoch seconds for compatibility reasons. Blah! I saw the prosal for an mjdate() routine and thought it was at the language level for some reason. This RFC should go to -internals so that I don't get confused that way :-) We may have ints of various sizes. (Or we may make it look that way but really fake it... :) Hard to say yet. As long as it Just Works from the language level, I don't care how it's done :-) my $i = 100_000_000_000_000_000;# big number! $i += 100_000_000_000_000_000; # even bigger! print "$i\n"; # Oh my gosh, it worked! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 83 (v1) Make constants look like variables
On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote: Well, just to counter argue, I feel exactly the opposite way. I'd like the keyword to be "constant" instead of "const". I've always thought "const" was a needless save of 3 characters. Constants should be obvious to pick out. The inventors of UNIX, when asked "What was your biggest mistake?" replied "Spelling creat() without the 'e'". Ditto here, IMO. Amen. Which is the easiest for anyone to tell what's going on? my num $PI : constant = 3.1415926; my num $PI : const = 3.1415926; my num $PI =| 3.1415926; Admittedly, "const" is pretty darn close to "constant", so tolerable. But =| is way too obscure, I think. Not only obscure but backwards IMHO. Rather than using some weird assignment operator to modify the attributes of a scalar (after all, constancy is a property of the scalar), better the attributes should be verbose and explicit. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: command line option: $|++
On Tue, Aug 15, 2000 at 09:14:20AM -0400, Casey R. Tweten wrote:
This, by the way (even as a test) was agravating to me because in order to
get decent output I really had to do this:
cat /etc/passwd | perl -nfe '$\="\n";print((split/:/)[0])'
cat /etc/passwd | perl -lnfe 'print((split/:/)[0])'
So perhaps we should allow all the 'special' variables, namely the
scalars, to be assigned to on the command line via thier English
representations. Observe:
perl -OUTPUT_AUTOFLUSH=1 -OUTPUT_RECORD_SEPARATOR="\n" -ne 'print((split/:/)[0])'
If you're going to be that verbose, might as well put that in the
program itself.
perl -lne 'BEGIN { $|=1; $/="\n"; } print ((split/:/)[0])'
Or something to that effect. However, I suppose the same could be done
with thier punctuation defaults:
cat /etc/passwd | perl '-$|=1' '-$\="\n"' -ne 'print((split/:/)[0])'
Ick.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
On Tue, Aug 15, 2000 at 12:08:52PM +0200, Bart Lateur wrote: On 11 Aug 2000 16:22:33 -, Perl6 RFC Librarian wrote: Currently, Perl uses the C library Clocaltime() and Cgmtime() functions for date access. However, because of many problems, these should be replaced with two new functions, Cdate() and Cgmtdate() Gee, yet again, we'll get two virtually identical but still separate functions. The original RFC tried to get rid of that, and replace them by just one function. Why did this sneak back in? Why is it yet again not possible to get the local time in another time zone? You're right, there should be just one date/time routine. But it is *extremely* difficult to incorporate time zones in a portable fashion. They change at legislative whim. But if utcdate() (or whatever we call it) had a way to specify an offset from UTC, that would be just fine. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: command line option: $|++
On Tue, Aug 15, 2000 at 10:03:55AM -0700, Nathan Wiger wrote: Jonathan Scott Duff wrote: Well, now it's my turn to suggest something ;- How about we give perl the ability to look for a .perlrc file? (Yes, I know the reasons against, but everything is up for grabs now right? :-) If we do this, it should be off by default. csk/ksh make you turn it off, which is the *WRONG* approach. Instead, add a boolean switch that says "reading ~/.perlrc is ok for this script". Maybe -r could be used for that. Scott, I'd suggest codifying ~/.perlrc in an RFC, real quick, before the heated arguments begin. :-) I'll RFC it later today probably. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Isn't that the way perl4 did it? I don't know what agony lwall and friends went through that made them change this behaviour though. It would be good for someone who does to speak up about it. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Default filehandles(was Re: command line option: $|++)
On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote: This is a succinct summary of the basic conclusions thus far: 1. a default filehandle IS needed sometimes, but only for stuff like print Well, I think that Cprint should always print to $PERL::STDOUT (or whatever we call it) always; same with Cprintf(). I'd hardly call that "default" though. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 104 (v1) Backtracking
On Wed, Aug 16, 2000 at 08:26:26AM +1000, Jeremy Howard wrote: Doesn't RFC 82 (Make operators behave consistantly in a list context) provide this functionality? This is perfectly valid under that proposal: @result = @a || @b; Which applies '||' component-wise to elements of @a and @b, placing the result in @result. I'm no Prolog guru, so feel free to correct me if I'm missing something here. I think you're missing the backtracking part (I'm no guru either). As I understand things: BLOCK1 andthen BLOCK2 evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2 evaluates to "false", then BLOCK1 is re-evaluated. Er, let me see if I can write the logic better: 1. eval BLOCK1 2. if "false", stop, else goto 3 3. eval BLOCK2 4. if "true", stop, else goto 1 It's kind of an all-or-nothing expression with side effects (evaluating the blocks). This sort of logic can be extended to N blocks too. Though I think if we're going to support backtracking like this, we'll need to support the cut operator as well (! in prolog) (Note the only prolog I've done was about 10 years ago for about 2 weeks and about 2 years ago for 2 or 3 weeks in a programming languages class at a university) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Default filehandles(was Re: command line option: $|++)
On Tue, Aug 15, 2000 at 06:53:30PM -0400, Chaim Frenkel wrote: What if you want to print to a default file handle and also to STDOUT? select(OTHERFH); print "This goest to OTHERFH\n"; print STDOOUT "This went to STDOUT\n"; print $_ "Here I come to save the day!\n" for ($PERL::STDOUT, $myfh); And again, if you want to print different stuff to different filehandles, you know how to use the print FILEHANDLE LIST; version of print. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On Tue, Aug 15, 2000 at 11:17:16PM -0400, Chaim Frenkel wrote: Sorry, I don't buy that. Not every program will be perl. Plus you are assuming that epoch seconds are good everywhere. And even if it were why should any other program use the same epoch. Well, we're not talking about *every* program...just those written in Perl. And epoch seconds *are* good everywhere if we make them good in Perl. The only valid interchange would be to specify the date unambiguously, for example the ISO mumble, help me Jarkko MMDDHHMMSS.fff That's an interface problem where perl meets the rest of the world. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 104 (v1) Backtracking
On Tue, Aug 15, 2000 at 08:59:25PM -0700, Mark Cogan wrote: At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote: Counter example:@a = \($a, $b, $c); I guess I'm missing the point; how is this different from @a = [$a,$b,$c]; Well, I've lost the point of this thread, but @a = \($a, $b, $c); is equivalent to @a = (\$a, \$b, \$c); rather than what you wrote. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
On Wed, Aug 16, 2000 at 12:14:09AM -0700, Nathan Wiger wrote: No problem. In fact, this fits under your rules. HOWEVER, it also assumes that Lincoln thought that param() was :lvalue-worthy. What if he forgot? Or didn't think of this case? Then you email him with a patch, and your reasons why your lvalue patch should be applied. If he likes it, it's included otherwise it's not. Don't second-guess the design decisions of module authors who may have perfectly good reasons for doing things the way they do. Worse, what if a somewhat novice writes a module and doesn't know about :lvalue, or at least not how to use it. But an experienced user picks up their module DoCoolStuff.pm on CPAN and tries it: Then that experienced user can patch the code and send email to the novice explaining lvalue subs and why he should use them. Ooops! The author didn't use :lvalue. So even though this makes perfect sense to be able to do, since the author forgot to use :lvalue, you lose a really cool syntactic tool. This seems backwards. Seems right to me. I'd rather assignment to a function work on purpose rather than on accident. If lvalue subs are the default, then they "accidently" work where maybe they shouldn't. Whether a sub should be lvaluable should be a conscious decision made by the subroutine author. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 104 (v1) Backtracking
On Wed, Aug 16, 2000 at 07:42:33PM +1000, Jeremy Howard wrote:
raptor wrote:
]- I tried minimalistic approach as small as possible additions to the
Perl
language, we get only the "backtrack" mechanism i.e. something that is
harder or slower to be done outside of the perl core.
The rest should be done outside . (I too want all in the core)
I don't know if you noticed the earlier thread, but there's a few people
(including myself) who are still having trouble understanding how your
proposal works.
Could you please provide a brief idiomatic example of some code where this
proposal would provide a real practical benefit--enough that slow learners
like myself can really understand what it makes easier, and how? It would be
great if you could provide the equivalent Perl 5 code too.
Here's some perl psuedo code that'll implement the "andthen" semantics:
BLOCK1 andthen BLOCK2 andthen BLOCK3 andthen BLOCK4
B1: if (BLOCK1) {
B2: if (BLOCK2) {
B3: if (BLOCK3) {
B4: if (BLOCK4) {
return "true"
} else { goto B3 }
} else { goto B2 }
} else { goto B1 }
}
return "false"
The semantics for "orthen" are similar:
BLOCK1 orthen BLOCK2 orthen BLOCK3 orthen BLOCK4
B1: unless (BLOCK1) {
B2: unless (BLOCK2) {
B3: unless (BLOCK3) {
B4: unless (BLOCK4) {
return "false"
} else { goto B3 }
} else { goto B2 }
} else { goto B1 }
}
return "true"
As for examples where this would be of benefit ... I really can't think
of any.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 110 (v1) counting matches
On Wed, Aug 16, 2000 at 03:04:19PM -, Perl6 RFC Librarian wrote: =head1 ABSTRACT Provide a simple way of giving a count of matches of a pattern. We already have this: $count = () = m/foo/g; =head1 DESCRIPTION m//gt would be defined to do the match, and return the count of matches, this leaves all existing uses consistent and unaffected. /t is suggested for "counT", as /c is already taken. Using /t without /g would be result in only 0 or 1 being returned, which is nearly the existing syntax. Better would be to redefine what m//g means in a scalar context. $_ = "foofoofoofoofoofoofoo"; $count = m/foo/g; 1 is just as true as 7. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 10:27:17AM -0400, Karl Glazebrook wrote:
Nathan Torkington wrote:
* current typing provides rudimentary compile-type checking.
Saying:
$foo = (1,3,5);
gives a warning. Saying:
this would create a $foo array
If () are array constructors, what is the hash constructor?
$array = (1,2,3);
$hash = qw(when Now where Here why Because);# Is it a hash?
Well, now that I've asked the question, I've thought of an answer ...
just use Damian Conway's pair constructor:
$hash = ('when' = 'Now', 'where' = 'Here', 'why' = 'Because');
Hmm. I wonder how you'd pairify a list though? Could that be one of
the unzip() or partition() routines?
Random musings (combining this and John Porter's collapse of arrays
and hashes):
$list = qw(when Now where Here why Because);
while ($list) { $hash[shift $list] = shift $list; }
$odds = map { $_%2 $list[$_] } 0..$#list;
$evens = map { $_%2==0 $list[$_] } 0..$#list;
$hash[$evens] = $odds;
for ($i = 0; $i scalar($list); $i+=2) {
$hash[list[$i]] = $list[$i+1];
}
Gee, I'd hate to lose simple assignment to a hash from a list.
What happens to $_ and @_? How do I get the arguments passed to a
sub?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
On Wed, Aug 16, 2000 at 08:40:18AM -0700, Nathan Wiger wrote: See, I don't see it as that big a deal, especially not if lvalue and rvalue subs work identically. Hrm. Perhaps you aren't explaining yourself clearly. Let's pretend that there is a magical value called $LVALUE that contains the thing being assigned. Are you saying that in somesub = $value; the subroutine Csomesub, being lvaluable by default is free to use or ignore $LVALUE? If so, how does one detect errors? When Csomesub is ignoring $LVALUE the above would silently fail, yes? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 10:38:30AM -0600, John Barnette wrote:
John Porter wrote:
Russ Allbery wrote:
$args = 'first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ = ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely.
No, it's not. Where are we taught this? It's a myth.
The punctuation imposes context on the variable expression.
$foo[0]
accesses an array. Where's the "@"?
It accesses an *element* of the array, which is a scalar. This scalar
might be blessed into a class, or a reference to an array or hash, but
the element itself is still a scalar. Where's the confusion?
I believe Mr. Porter is refuting the claim that "the punctuation is
part of the variable name". As both he and you have demonstrated,
it's not.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 12:44:50PM -0400, John Porter wrote: Jonathan Scott Duff wrote: Gee, I'd hate to lose simple assignment to a hash from a list. foo %= bar; Hmm, I think I need to write an RFC! I'll give you my comments right now ... It seems we are eliminating punctuation to make the language simpler in one respect, yet, because of that, creating new punctuation so that we can use the language in ways we are used to. If that must be the case, then I say, if it ain't broke, don't fix it! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Wed, Aug 16, 2000 at 12:48:12PM -0400, Dan Sugalski wrote: At 11:09 AM 8/16/00 -0400, John Porter wrote: The difference between numbers and strings is analogous to -- or, on further reflection, IDENTICAL to -- the difference between arrays and associative arrays. (The former are numerically indexed, the latter indexed by strings.) The analogy doesn't hold. And people treat arrays and hashes *very* differently, far more so than the trivial differences in the notation might lead you to believe. Could you come up with concrete examples that illustrate this point? What would stop people from treating arrays and hashes differently if the trivial notational differences are removed? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 10:04:22AM -0700, Damien Neil wrote: I'm not certain that I like the idea of string-indexed arrays; I don't know that I like the thought that $a[5] and $a[05] might suddenly mean something different. They wouldn't. In $a[05], 05 is a number. To get a string, quotes would be needed. As for $a[$something], if @a had been declared as "my @a : assoc;", then perl should stringify $something, otherwise numify. Hmm.. I guess this implies that all hashes need to be pre-declared. :-( -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 114 (v1) Perl resource configuration
On Wed, Aug 16, 2000 at 01:07:24PM -0700, Peter Scott wrote: At 08:03 PM 8/16/00 +, Perl6 RFC Librarian wrote: Perl should provide a mechanism to have common code autoloaded from a file. Please, no. It's the ultimate scary action-at-a-distance. If the programmer *wants* action-at-a-distance, Perl has never stood in the way. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Ideas that need RFCs?
On Thu, Aug 17, 2000 at 01:07:30PM -0400, Stephen P. Potter wrote: * Replace Cm//, Ctr///, and Cs/// with equivalent regularized functions that take mulitple arguments instead of using specialized syntax. It would be best if the names could be more "complete", like match(), translate(), and substitute() (although translate and substitute are rather long). This one puzzles me. Someone suggested that we remove one of the reasons I use perl rather than awk or python? Some of these are mine, some of them are ideas I remember seeing someone else mention, but I don't see RFCs for. Am I missing them, or do they need to be written up? RFC away! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
On Wed, Aug 16, 2000 at 10:59:38AM +0100, Piers Cawley wrote:
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
This RFC proposes that lvalue subs, when invoked as such, should receive
the rvalue being assigned to it as an argument.
I'm kind of in two minds about this. Most of the time the current
lvalue behaviour does pretty much the Right Thing, and simple lvalue
subs are simple to write. If you end up with the rvalue as an extra
argument you end up having to dance around whether or not the sub is
called in an lvalue context to possibly decide what to do with the
argument.
Passing the lvalue via some other means eliminates this problem. I
forget who suggested it (Buddha Buck?) but
sub foo : lvalue($value) { ... }
where $value is a reference to the thing we're assigning seems like a
Good Idea to me.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: implied pascal-like with or express
On Thu, Aug 17, 2000 at 10:48:25PM -0500, David L. Nicol wrote:
Lets use hats again then.
%ws{
print ^$height; #prints $ws{height}
print $height; # perl5 visibility rules
};
But no $ for the keys of %ws.
%ws {
print ^height; # prints $ws{height}
print $height; # prints $height
}
Something else to consider is that with some of the other proposed
features in perl 6, we could probably implement this functionality in
Perl. Do we want to make it part of the core or in a library?
BTW, if we define Cwith to map keys of a hash to named place holders
in a curried expression, this might be a good thing:
with %person {
print "Howdy, ", ^firstname, " ", ^lastname;
}
# becomes
sub {
print "Howdy, ", $person{$_[0]}, " ", $person{$_[1]};
}-('firstname', 'lastname');
# becomes
print "Howdy, ", $person{'firstname'}, " ", $person{'lastname'};
(If that's what people meant, I didn't see anyone actually say it).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 124 (v1) Sort order for any hash
On Fri, Aug 18, 2000 at 09:31:44AM +0100, Hildo Biersma wrote:
Ah, syntax - I have no idea.
Well, syntax aside, how would this work?
One thing we could do, theoretically:
%hash = ('James' = 'Gibbon',
'Dave' = 'Mallon',
'Pete' = 'Munro');
while (my ($key, $value) = each alphabetic %hash) {
...
}
Does the presence of an ordering subroutine cause perl to generate a
linked list of all the elements of the %hash in the proper sequence
prior to iteration (and somehow attach it to the iterator)? Seems
like everytime we did that it would generate a new operator:
while (my ($key, $value) = each alphabetic %hash) { # 1
while my ($k2,$v2) = each crazy_order %hash) { # 2
...
}
}
At #1, the iterator would really be an each_alphabetic and #2 would really
be an each_crazy_order rather than a generic iterator. (Unless you really
want the iterator to compute the next in sequence on each iteration)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: implied pascal-like with or express
On Fri, Aug 18, 2000 at 10:39:36AM -0500, Brian Wheeler wrote:
"Using" might be an interesting alternative
Reminds me of BASIC :-)
What if the hash keys we want to use are not valid scalar names? For example,
I've had keys like "total - female" as keys, but using the ^ syntax
would fail on this...
Good point. But who's to say that ^{total - female} doesn't work?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 23 (v3) Higher order functions
On Sat, Aug 19, 2000 at 06:35:55AM +1000, Damian Conway wrote: You're error is in assuming I have time *now*. With 30+ RFCs still to write, I've been seriously contemplating just abandoning the Perl 6 effort, because added to the demands of my full-time job, my O'Reilly and other tutorial commitments, my modules, and my poor long-suffering and cruelly-neglected wife, the stress is beginning to affect seriously my health. Well, I guess you'll have to abandon the wife and whatever sleep you may get now. ;-) Seriously though, if you're that overloaded, farm out your ideas to other willing souls who may be able to express them as you would in the form of an RFC. Similar with the modules. It'd be a shame to lose your (IMHO) valuable contributions to the Perl 6 effort. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 08:40:32PM -0700, Nathan Wiger wrote: No, but currently Perl IS forcing Windows, Mac, and BeOS users to understand what the UNIX epoch is. So you're proposing that rather than give one platform (unix) an advantage, we force all platforms to use some other completely arbitrary date/time format? There's some other advantages to MJD beyond system-independence. Namely, it allows easy date arithmetic, meaning complex objects are not required to modify dates even down to the nanosecond level. Sorry, but date arithmetic is easy now: $then = time(); # time passes $now = time(); $difference = $now - $then; # How long was that? And as to modifying dates "down to the nanosecond", you're proposing that these MJD dates be floating point numbers. Why not ust make time() return a float and *bam* you've got 1 second precision as far as your floats or doubles can carry you. But make the core language easily accessible to everyone. Funny, that's the exact argument I would use *against* mjdate(). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: ... as a term
On Mon, Aug 21, 2000 at 09:09:01AM -0700, Larry Wall wrote:
Randal L. Schwartz writes:
: if ($a == $b) { ... } # should this be string or number comparison?
Actually, it's a syntax error, because of the ... there. :-)
But that reminds me of something I wanted a few months ago.
I'd entertain a proposal that ... be made a valid term that happens
to do nothing, so that you can run your examples through perl -c for
syntax checks. Or better, make it an official "stub" for rapid
prototyping, with some way of getting a warning whenever you execute
such a stub.
Just to clarify, you're proposing that ellipsis do this in void
context only, right? I kind of like the existing ... operator just
the way it is (unless it has changed behind my back).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: functions that deal with hash should be more liberal
On Mon, Aug 21, 2000 at 09:00:26PM -0400, Casey R. Tweten wrote:
Today around 3:34pm, Tom Christiansen hammered out this masterpiece:
: No. keys() expects something that starts with a %, not
: something that starts with a .
Wow. Now that, that, is lame. You're saying that keys() expects it's first
argument to begin with a %? Why should it care what it's argumen begins with?
It cares because it is only defined to operate on hashes. A list is
not a hash.
All functions recieve their arguments in a LIST via @_. Since func, in the
above example, returns a LIST, that LIST should just be passed on.
Exactly. This is what happens. keys() doesn't operate on lists.
keys( @array );
So this would "convert" @array to a hash and take the keys of that?
Or does it (as some have proposed) return the keyable indices of
sparse array?
Otherwise, work something like this:
sub keys {
my %hash = @_;
return keys %hash;
}
Ah, convert is argument to a hash then grab the keys of that hash.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: ME
On Wed, Aug 23, 2000 at 11:59:15PM -0400, Buddha Buck wrote: How about a @CALLER array, with each element being a reference to the invoking function in the call-back stack. $CALLER[0] would be equivilant to \ME, $CALLER[1] would be the sub that called ME, etc, and then $CALLER[-1] would logically be the main program. How about we change what caller() returns in scalar context? Rather than just the package name, it could be an "object" that represents my $ME and all of the $MEs available on the stack. It could still return the package name in "string context" I guess. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: User-defined quoting operators
On Thu, Aug 24, 2000 at 10:59:07PM -0700, Peter Scott wrote: So what about the possibility of user-defined q[a-z]// (using a letter that hadn't already been taken), where you get to specify the actions of =~ and probably more operators? Sounds like it has a lot in common with operator overloading - maybe even just an extension to overload.pm? Sounds exactly like operator overloading. I think that user-defined qX is a red herring though because we already have user defined subroutines and the quotators are essentially that. We just need a way to overload the binding operator (I didn't see it mentioned in a quick skim of overload.pm) so that THING =~ OTHER_THING is translated to bind(THING,OTHER_THING) with bind() having user-defined semantics. I think Damian has an RFC in-the-works on operator overloading that will address this. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Multiple for loop variables
On Tue, Aug 29, 2000 at 09:21:32AM -0400, Eric Roode wrote: I'm not seeing an earth-shattering advantage of: for my($k,$v) (%hash) over while(my($k,$v) = each %hash) AFAICT, they act the same, just look a little different. Eight characters difference, counting whitespace. What's the "earth-shattering advantage" of "=" over ","? Answer: there isn't one. A common task was just made easier through a simple addition to syntax. Why not the same for loops? People keep proposing bells, whistles, antennae, and tentacles for the "for" statement, and I haven't seen one yet that had seemed justified to me. What's "justified"? It sounds like you're arguing "we already have a way to do it, let's not make another" even if the other way makes it *easier* to do the thing. Remember, Perl's motto is TMTOWTDI and that's not by accident. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 33 (v2) Eliminate bareword filehandles.
On Wed, Aug 30, 2000 at 02:47:46AM +0200, Bart Lateur wrote:
On Tue, 29 Aug 2000 18:17:46 -0600, Tom Christiansen wrote:
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
Aha! You fell for one of my pet pieves. You tried to return a lexical in
the same expression were it was declared. That doesn't work. It's not
the same variable.
Perl is starting to feel more like C in this instance :-(
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Proposal: chop() dropped
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote: chomp() is best used for chop()s main raison d'etre, removing $/ from a string. I say we drop chop(). I'll second that motion. We already have lots of ways of removing the last character of a string if that's what we really need. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Proposal: chop() dropped
On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote: Why not use the "function" we already got, tr? Something like: tr///l # Translate only _l_eading characters matching. tr///t # Translate only _t_railing characters matching. With "Only leading" I mean translate from start/end until you find a character not matching. Then you can do nifty things such as: Um, that would radically change the meaning of tr///. Better to use s/^// and s/$//. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Pre-withdrawal notice for RFC184
On Tue, Sep 19, 2000 at 09:23:00AM +0300, Ariel Scolnicov wrote:
I'm planning to withdraw RFC184 ("Perl should support an interactive
mode"), due to lack of interest.
I'd say leave it in. What could it hurt?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 76 (v2) Builtin: reduce
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Builtin: reduce
...
Collection:
@triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
You've a typo there, it should be:
@triples = @{ reduce sub($;$$$){ [@{shift},[@_]] }, [], @singles };
Separation:
$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
[[],[]],
@numbers;
I don't understand this one.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 76 (v2) Builtin: reduce
On Wed, Sep 20, 2000 at 07:31:35AM +1100, iain truskett wrote:
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Builtin: reduce
[...]
Separation:
$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
[[],[]],
@numbers;
I don't understand this one.
$sorted = reduce { push @{ ^0 [ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
I guess I'm confused with the syntax. Shouldn't there be an - in
there?
$sorted = reduce { push @{ ^0-[^1%2] }, ^1; ^0 }, [[],[]], @numbers;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 76 (v2) Builtin: reduce
On Wed, Sep 20, 2000 at 08:22:38AM +1100, iain truskett wrote: I'd believe so. I think I mentally assumed that Damian was grabbing a syntax trick from another RFC. Heh, I think the exact same thing is what confused me :-) I must say that the ^0, ^1 style notation really makes some expressions much more legible. Indeed. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 288 (v1) First-Class CGI Support
On Tue, Sep 26, 2000 at 12:04:50AM -0400, Adam Turoff wrote: On Mon, Sep 25, 2000 at 07:50:28AM +0100, Richard Proctor wrote: On Mon 25 Sep, Perl6 RFC Librarian wrote: Turn on tainting What would it do on a platform that does not support Tainting? Is this a real issue? Is there a platform where tainting isn't supported? I wouldn't think so. Tainting is a Perl thing. Perl does it's best to mark "unsafe" things as tainted. What's unsafe and Perl's best vary from platform to platform, but tainting still happens. (But this is from a guy who has only used but 6 or 7 of the OSes that Perl has been ported to) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 290 (v1) Remove -X
On Tue, Sep 26, 2000 at 12:34:00AM -0400, Adam Turoff wrote: Making '@permissions = -rwx $filename;' work is an interesting new suggestion. Yep. Of course, I should say that I've been hanging out with some snake-hearders recently. Hey, we could learn a thing or two from some snake herders. (Watch how they get bit and don't do the same ;-) I'll revise the RFC to add 'readable()', 'writable()', and such synonyms for -r and -w that are more like 'use english' and less like 'use English'. Excellent. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 320 (v1) Allow grouping of -X file tests and add Cfiletest builtin
On Tue, Sep 26, 2000 at 05:53:13AM -, Nate Wiger wrote:
Currently, file tests cannot be grouped, resulting in very long
expressions when one wants to check to make sure some thing is a
readable, writeable, executable directory:
if ( -d $file -r $file -w $file -x $file ) { ... }
Non-novice perl programmers would probably write this as you have
below with the special _ filehandle. Perhaps you should move that to
the fore and comment on it's unreadability and general ickiness :-)
It would be really nice if these could be grouped instead:
if ( -drwx $file ) { ... }
Indeed it would.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
split() ideas
I thought I had sent this the other day, but it doesn't appear to have made it through... Here are a couple of ideas that I don't have time to RFC, but some who likes them might: 1. Allow the first argument to split() to be a number such that the string is broken into chunks of that many characters. 2. Allow the first argument to split() to be an array of numbers, such that split returns a list of strings each as long as the corresponding number. Yes, I know this can be done with unpack() or substr(), but that's never stopped us before. Note that if #1 is adopted, $foo in "split $foo, $str" will no longer really mean "split /$foo/, $str". -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to core distribution
On Thu, Sep 28, 2000 at 03:22:08PM -0600, John Barnette wrote: Perl6 RFC Librarian (Today): =head1 TITLE Add Cheader and Cunheader funtions to core distribution While I'm not sure if this belongs in the core or not, I think it's nifty, and I'd like to point out an almost inevitable side effect. Knowing well the nature of Perl hackers, this function will almost certainly be used for non-header tasks such as config files, as the data format used in most plaintext headers is both simple and general. Add comment detection to the parsing, f'rinstance, and this is quite similar to a Java Properties file. My first thought was "this should definitely be in a module" and your comments just fire those synapses even more strongly. To me core-worthy things must be primitivish. The idea of colonizing and s/_/-/g and ucfirst()ing each word and adding newlines or reversing all of that seems so unprimitive. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote: =head1 TITLE Perl should use XML for documentation instead of POD Wow. I'll just add my voice to the others. POD is more readable than XML. As Nathan Wiger said, just read the HTML vs the POD for the RFCs. But, why not suggest SDF instead of XML? SDF addresses most of POD's deficiencies whill still retaining readability. (I don't have a URL for SDF handy, but I'm sure a quick search on google.com would turn it up) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [Fwd: Re: [FWP] sorting text in human-order]
On Fri, Dec 29, 2000 at 11:47:59PM -0600, Jarkko Hietaniemi wrote: The sorting algorithm? Before 5.005 (I think...my memory is going) vendors' quicksort, after that Tom Horsley's excellent ultratuned quicksort (since vendors' quicksorts were (a) buggy (c) slow), in 5.7 mergesort by John Lindermann was introduced. Could someone give me a pointer to the whys and wherefors of the change from quicksort to mergesort? thanks, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: very basic question
On Mon, Jan 29, 2001 at 11:37:22AM -0800, Mark Koopman wrote: where are all RFCs posted for perl6? is this the main discussion board for perl6 development, or has the development broken down into separate group-lists? if it's broken down, where would i find a listing of lists? http://dev.perl.org All will be made clear there. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote: I propose the introduction of two new keywords (just like `my' and `our') for specifying a different scope: `global' and `outer'. `global' would be used to say that a specific variable or a list of them would refer to the global variables with those names in the current package. What are "global variables"? Do you mean those that have file scope? Variables accessed with their explicit full packagenames would be the global variables. Wait, I thought we were talking about lexicals, not dynamics. Actually, what I'm proposing is quite very different than `upvar'. `upvar' is a dynamic thing, it accesses a variable in the scope of the caller. `outer' is a lexical thing, it tells the compiler that that variable name is accessing the same variable that the definer was accessing. I'm confused. Consider also I'm not wanting you to use it, or like it whatsoever. I only think it would probably be useful for some of us, and that only adding a new `scope' pragma wouldn't hurt anybody, while possibly helping some. Perhaps. Except that you also propose to burden the language with two new keywords. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. We already have a switch that means "quick and dirty", it's called "-e" -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
On Fri, Feb 16, 2001 at 01:20:43PM -0300, Branden wrote: `my' DWIMs. `my' will do what *you* mean at the cost of every single existing perl programmer that currently uses it to relearn what it means. Not a good trade off IMHO. I'd rather `my' does what *I* mean which is what it does now. I know this is bad for who already writes Perl code. But it would be very good for who learns Perl and doesn't understand exactly when he should and when he should not put parenthesis around `my's list of variables. If they are learning perl, then when and where to use parentheses is part of the learning curve. This is a Good Thing. MHO, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 02:36:40PM -0400, John Porter wrote: Larry Wall wrote: There will probably be optional modifiers before colon for various reasons. This has the result that we could distinguish an inner:* operator from and outer:* operator. I balk at the proposition of Yet Another Namespace. Doesn't look like another namespace, but rather an extension of an existing one to me. It might even mean that we can have a URL literal type, I trust that you will think long and hard about that. Gosh I hope so ... my first reaction was that Larry had gone insane when I saw that http://... example. But let him digest those beans completely and we'll see what he comes up with. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 03:32:56PM -0400, John Porter wrote: Jonathan Scott Duff wrote: Doesn't look like another namespace, but rather an extension of an existing one to me. An extension of a namespace? What's that? Either "modifiers" will be symbols in an existing namespace, or they will be in their own namespace. I was rather thinking that we could extend the subroutine namespace to include the funny symbols and that modifiers would exist there. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Mon, Apr 16, 2001 at 12:19:38PM -0700, Peter Scott wrote: Er, I don't get it. I'm proposing that if perl 6 determines it's been given perl 5 code, it does "exec perl5 $0". So thereafter it's as though perl 6 never existed as far as that code is concerned; whatever it wants to do should be completely independent of any perl 6 code. So ... when a "perl6" program uses a "perl5" library, what happens? If we go with Larry's rule that a package declaration unambiguously says you're parsing perl 5, then this situation WILL exist. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
