Re: Exceptions and Objects
Jonathan Scott Duff wrote:
On Sun, Aug 13, 2000 at 07:27:47PM -0700, Peter Scott wrote:
An error has text associated with it, but also a bunch of other
attributes.
So it's a structured data type... where does OOP come into play?
1. It allows you to *extend* the base type with new attributes
without having to re-implement all the base attributes.
2. It allows you to *extend* the base type with new methods that
can, say, compute predicates based on the object's attributes.
Then, you can say things like:
if ( $@-isa(MyException) $@-CanFoo ) { ... }
3. Is allows you to *override* base class behaviour, for example,
by changing the way stringification works for some classes, or
by modifying a constructor to do some sort of logging, for some
class of exceptions.
They fall naturally into different classes, some of which have
subclasses (a File error is-a IO error).
This, to me, seems a mere matter of naming. Was it that OOP already
had a hierarchical naming system and so it was used?
Once the other good reasons for OO exceptions come into play, you
may as well take advantage of the serendipity.
What does it mean for an exception to have semantics? When an
exception is thrown does something special happen whether it's
caught or not?
$@-CanFoo is an example of semantics that determines whether or
not the exception is caught; stringification may be an example
of semantics that comes into play when an exception is caught.
Yours, c, Tony Olekshy
Re: Exceptions and Objects
Piers Cawley wrote: Tony Olekshy writes: Peter Scott wrote: An exception is an 'error'. That's already a vague concept. I'll say it's vague. There are certainly uses for an exception to trigger non-local success, not an error at all. In fact, there are whole programming techniques based on such uses. Just because most of us usually use exceptions to handle errors, that doesn't mean Perl should not support other uses. Ah, the 'Bloody hell it worked! That's exceptional' style of programming? Yup. But I couldn't have said it better than you just did. Yours, c, Tony (TIMTOWTDI) Olekshy
Re: errors and their keywords and where catch can return to and stuff like that
From: "Peter Scott" [EMAIL PROTECTED]
Sent: Sunday, August 13, 2000 10:35 PM
try {
# fragile code which doesn't call any subroutines that might die
# and doesn't include any other try blocks
} catch {
# No code at all
}
Well, I don't really like that solution. It's exactly the same situation as
use strict / use warnings, BTW. I don't much like that either, but... In
any case, there we have exactly the situation we're speaking about (well, in
warnings, anyway) -- a heirichy of exceptions.
Therefore, I think we want some generic mechinisim to say what the behavor
of an uncaught exception is.
My proposal is:
$Exception::whatever::onuncaught = CODEREF.
Yes, this is a global. It has to be; the definition of when/how this gets
called is that if the unwind stack goes all the way /past/ the root of the
code, this code ref gets called. The only parameter is the exception. The
defalut would be sub {die shift;} (for "obviously" fatal things), which
would make the program exit with a fatal exception. Other normal choices
would be undef, ignore it (non-defualt warnings, like bareword), and sub
{warn shift;}, print out a warning message (default warnings, like... I
can't think of any).
The value of onuncaught should follow isa if it doesn't exist.
-=- James Mastros
Re: errors and their keywords and where catch can return toand stuff like that
I think folks are forgetting that there are more than one client for
any class. Global settings should be restricted to a single setter.
The only logical single setter is main. All other clients should
be using something local.
Another reason to avoid globals, is we are designing perl6 to be thread
friendly. Adding globals (this includes read-mostly access) adds overhead,
cost and yet another variable that increases deadlock potential.
Just say no to globals (as much as possible)
chaim
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS Everyone seems to have started thinking about the implication of
PS inheritance in exception classes at the same time. Whatever the default
PS behavior is, we can easily change it on a global basis (using Chaim
PS Frenkel's sub name here);
PS sub Exception::uncaught_handler { maybe rethrow, maybe not }
PS Or a per-class basis:
PS sub Exception::IO::uncaught_handler { ... }
PS Or a per-object basis (gross as I find this):
PS my $e = Exception::SQL-new(...);
PS $e-uncaught_handler = sub { ... }
PS throw $e; # or maybe throw Exception::SQL(uncaught_handler = sub { ...
PS }, ... );
PS And the dispatcher would look first in the object, then in the class for
PS uncaught_handler.
PS I think it's cool how this process is converging :-)
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Exceptions and Objects
Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 04:09:41AM -0600, Tony Olekshy wrote:
$@-CanFoo is an example of semantics that determines whether or
not the exception is caught; stringification may be an example
of semantics that comes into play when an exception is caught.
Ah, this is why I started asking I guess. Some people were proposing
a try/catch like the following:
try { }
catch SomeException { }
catch SomeOtherException { }
finally { }
which seems to only catch exceptions based on name. Which implies to
me that, for exceptions to have useful semantics, they'd have to be
rethrown after they're caught. I like the following, but it would
also seem that exceptions that aren't handled here would have to be
rethrown so that an upstream catch could handle them.
try { }
catch { # ALL exceptions
switch ($@) {
case ^_-name eq 'IO' { ... }
case ^_-canFoo { ... }
throw $@; # No cases matched, rethrow
}
}
finally { }
This is why RFC 88 is working on syntax and semantics for:
try { ... } except sub { $_[0]-CanFoo } = catch { ... }
which *does* unwind if $_[0] can't Foo (or, if $_[0]-CanFoo or the
catch clause throws).
Yours, c, Tony Olekshy
Re: errors and their keywords and where catch can return toand stuff like that
Evan Howarth wrote:
Tony Olekshy wrote:
Just be sure to arrange to handle exceptions while handling
exceptions.
Are you saying that the try-catch proposal automatically
handles exceptions thrown in catch and finally blocks?
Yes.
That's an interesting idea. Java, C++, and Delphi don't do
that for you. They expect the programmer to either avoid
or correctly handle exceptions in catch and finally blocks.
Right, and in practice, it drives me nuts, because if I have
a try, a conditional catch, and a finally, I want the finally
to happen whether or not the code in the catch throws.
How does try-catch handle exceptions in catch and finally
blocks. Does it just eat them?
The basic syntax considered in RFC 88 is:
try { ... throw ... } # try clause
except TEST = catch { ... }# 0 or more
catch { ... } # 0 or more
finally { ... } # 0 or more
unwind { ... }; # 0 or 1
The basic semantics are:
* The try clause is evaluated.
* Each catch clause is invoked, but only if an exception has
been raised since the beginning of the try statement, and
the catch clause's except TEST is true or is not given.
* Each finally clause is invoked whether or not an exception
has been raised since the beginning of the try statement.
* The unwind clause, if any, is invoked if an exception has
been raised since the beginning of the try statement, and
it has not been cleanly caught.
* After processing all clauses, try unwinds (dies) iff any
exception wasn't cleanly caught.
An exception is considered to be "cleanly caught" if it was in
the try clause, and it triggered a catch clause, and no catch
or finally clause raised an exception. There are some other
semantics that come into play with multiple catch clauses, for
detailed information see RFC 88.
Yours, c, Tony Olekshy
Re: errors and their keywords and where catch can return toandstuff like that
Peter Scott wrote:
Tony Olekshy wrote:
When you want the first one, use try + catch.
When you want the second one, use eval, then manipulate $@.
Just be sure to arrange to handle exceptions while handling
exceptions.
Erk, people shouldn't have to use such radically different
syntax for a tiny semantical change.
They don't have to. They can just use a try with an empty catch,
which is what Peter and I wanted in the first place.
I was only pointing out that there are two camps involved here,
one of which likes eval semantics and the other which likes try
semantics. If we leave eval alone in Perl 6, and add try, then
everyone should be happy, and there will be one less potential
problem converting Perl 5 code. We may need not even need to add
try to the Perl guts (RFC 88 as implemented in Perl 5 is a module
that adds try, so perhaps all we need is a core module and possibly
an efficiency hook or two).
Everyone seems to have started thinking about the implication of
inheritance in exception classes at the same time. Whatever the
default behavior is, we can easily change it on a global basis
(using Chaim Frenkel's sub name here);
sub Exception::uncaught_handler { maybe rethrow, maybe not }
Or a per-class basis:
sub Exception::IO::uncaught_handler { ... }
Or a per-object basis (gross as I find this):
my $e = Exception::SQL-new(...);
$e-uncaught_handler = sub { ... }
throw $e;
And the dispatcher would look first in the object, then in the
class for uncaught_handler.
Ideas about exceptions and exception handling are easy. Getting a
suite of ideas to cooperate in practice can be more difficult. For
example, with
try { throw Exception1-New; }
catch { throw Exception2-New; }
does the uncaught_handler of Exception1 get called? One could say,
"no, because it was caught", or "yes, because it wasn't fully
caught, because the catch didn't complete".
And by the way, what's supposed to happen when an uncaught_handler
throws?
I'd like to see some working code excercising uncaught_handler, with
documentation and regression tests I can study. One could base such
an implementation in the code referenced in RFC 88.
I think it's cool how this process is converging :-)
Yes, but let's not get carried away. We have to try to come up with
a clean set of basic concepts that work well in the easy easy, hard
possible sense. If we want to use unwinding with exception objects
as the basis for Perl's failure handling, then we *certainly* don't
want a fragile exception handling mechanism compounding the failure
for us. What is the cost of an accidentally lost throw when you are
using exception handling for error handling? As Henry Spencer used
to say, "then all bets are off".
If you don't like food-for-thought digressions, skip this paragraph.
Say you and I are playing a game of catch (the verb). We can throw
a football, or a baseball, or a frisbee, all using the same basic
throwing and catching mechanism. We can teach that mechanism how to
handle different classes of throwable-catachables, but we can't
teach it to throw or catch 16T blocks. And in no case is the object
being thrown allowed to reach out and change my hand into a foot.
Yours, c, Tony Olekshy
Re: errors and their keywords and where catch can return toandst uff like that
Peter Scott wrote:
If anyone suggests that
try { }
catch Exception::Foo, Exception::Bar { ... }
catch { exception thrown here causes it to
start going through catch blocks again }
then I'm afraid I'm going to have to turn to drink.
Agreed. However, consider this:
try { may_throw_1; }
catch { may_throw_2; }
catch { may_throw_3; }
finally { may_throw_4; }
Under what conditions should the second catch clause be invoked?
Under what conditions should the above unwind after finally (vs
continuing the normal order of execution? RFC 88 currently goes
into the second catch if the first catch throws, but perhaps it
should go straight to the finally if any catch throws.
Or maybe not. Consider this case (in pseudo-syntax):
my $o = SomeClass-New;
try { f ($o); }
catch $@-ImpliesFooCleanup { $o-AttemptFooCleanup; }
catch $@-ImpliesBarCleanup { $o-AttemptBarCleanup; }
finally { $o-Done; }
If you would want to attempt bar cleanup even if attempting
foo cleanup fails (throws), then RFC 88 gets it right (the
syntax is different, and the unwind stack is used to prevent
the second exception from hiding the first one, but it works).
We either have to disallow multiple and conditional catches
and move everything to a catch-all block and do all the
flow control manually (for which we already have eval {}),
or we have to specify the semantics for multiple conditional
catches.
Yours, c, Tony Olekshy
RE: Unify the Exception and Error Message RFCs?
This seems like a good idea, to me. -Corwin From: Steve Simmons [mailto:[EMAIL PROTECTED]] IMHO trading six RFCs for two will greatly improve the chance of passing.
Re: RFC 14 (v3) Modify open() to support FileObjects and
What does that mean? When the handler is invoked, what does it see?
$fh = open myhttp "http://www.perl.com", "fred", "barney";
Does that result in a call like this?
myhttp::open("http://www.perl.com", "fred", "barney");
Exactly. Or to be "more correct"
myhttp-open("http://www.perl.com", "fred", "barney");
Why strip anything? Just pass the string to the handler verbatim. It
would certainly seem weird to me if URI-handlers got something
different than other special-purpose handlers.
imagine
http::open("www.perl.com", "fred", "barney"); # weird
myhttp::open("http://www.perl.com", "fred", "barney");
/imagine
That's fine by me. I'm going to put out an RFC today on embedding full
URI support, since nobody has yet. We can discuss this more then.
If no handler by that name has been
registered, undef is returned.
Where are these handlers registered? How are they registered? In my
mind I was thinking that we could just name our handlers as packages
so that
$fh = open "http://www.perl.com"; # and
$fh = open myhttp "http://www.perl.com";
would cause Perl to search @INC for http.pm and myhttp.pm and auto-use
them.
Basically, you're right. I'll have an RFC out later today on handlers
and pseudo-classes. A handler is just = 1 class. The RFC on AUTOLOAD
being able to decline a request? Same idea. Think Apache handler. All
will become "clear" soon... :-) :-) :-)
-Nate
Eliminate dynamic variables entirely?
Here's a radical thought: In most languages, dynamic scoping of variables offers no advantages over lexical scoping, other than dynamic assignment. Dynamic assignment can be accomplished with the local() operator (soon to be renamed, I hope). The local() operator can be extended to operate on lexical variables as well as (or instead of; read on ...) dynamic variables. The package command was created in order to allow for different namespaces that would not conflict, back when lexical variables were not available at all in Perl. Now it has been extended for O-O classes. The following changes could be made involving lexical variables and packages in order to eliminate dynamic variables from the language entirely: *) Dynamic variables no longer exist. *) Lexical variables belong to the package they are declared in. (Or, if not declared, the package to which they belong can be inferred.) *) Lexical variables can only be accessed from within the same scope or a lower scope. This means lexicals declared in the same file can be accessed if they belong to a different package, but lexicals declared in another file cannot be accessed directly. *) In nearly all cases (hopefully approaching the magic 80% translate 100% correctly, 95% translate 95% correctly), a package (dynamic) variable can be translated into a lexical variable defined in a .pm file along with a class accessor method (standard get/set functionality). I'm thinking cases where this wouldn't work, if there are any, would be so esoteric that someone would want to port them by hand, anyway. *) Packages still continue to function in the same way to define classes. *) Packages still continue to provide a separate namespace for non-O-O subroutines. This enforces the lexically-scoped variable paradigm even more, and best of all, *the implementers only have to worry about one type of variable!* Perl could cease to look like lexical variables were hacked onto the side to fix a problem. If people really want true dynamic variables, there could be a pragma. ... Results are left to the imagination. (In this case, I suppose Perl would look like lexical variables designed in with dynamic variables hacked onto the side. Still an improvement, I think.) Still trying to cause trouble, J. David
Re: Eliminate dynamic variables entirely?
Nathan Wiger wrote:
However, make lexicals the default so that MyPackage would have to look
like this:
package MyPackage;
# my is redundant since lexicals are default
my($internal1, $internal2) = ('value1', 'value2');
# have to use your to give this variable to other packages
your $DEBUG = 0; # $MyPackage::DEBUG now dynamic
how is "your" different from "our"?
use MyPackage;
our $DEBUG=1;
I think something like this is a good idea. It's more intuitive too -
hide your variables in your package unless you *want* to give others
access to them.
If you're going to write an RFC on this, cool. Otherwise I will, just to
keep it interesting. In particular I've "fallen in love" with the
"your()" keyword. :-)
maybe i missed something. is this really only "your" variable or do we have
access to it in "our" package when code is executing within it?
-Nate
Here's a great p5p message on Perl lexicals vs. globals/dynamics:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg00839.html
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
Yet another lexical variable proposal
=head1 TITLE
Yet another lexical variable proposal: lexical variables made default
without requiring strict 'vars'
=head1 VERSION
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: perl6-language-strict
Number:
=head1 ABSTRACT
Perl was originally designed around dynamically-scoped variables.
Many users would like to see this design flaw fixed, but are disagreed
about how to go about it. This proposal suggests making undeclared
variables be lexical by default in Perl6 and deals with the possible
ambiguities this could bring about. An optional suggestion is made as
to how one might go even further and eliminate dynamic variables
entirely from the language.
=head1 DESCRIPTION
Lexically-scoped variables are easy to use and intuitive, in that any
lexical variable refers to a variable declared within the current
scope or the enclosing scope. The variable can be located by
lexically scanning the source code. Dynamic variables, on the other
hand, refer to a variable from within the current scope or from within
the current subroutines _caller_, which could be anywhere! It is
impossible to tell exactly what else might be happening to a dynamic
variable, resulting in various action at a distance problems, variable
suicide problems, and other difficulties.
Under this proposal, lexical variables are considered to be the norm
for Perl6. Any undeclared variable is considered to be a lexical
variable.
=head2 Scopes
An undeclared variable is lexical and visible only within the scope
where it is first used and any scopes contained within that one. The
notion of "scope" is the same as Perl has had almost since the
beginning: a block (including a subroutine block) begins a new scope;
a file is also a scope.
Thus, in the following code segment,
$x = 15;
$y = $x;
while ($y) {
$z = $y;
...
$x += $z;
}
$x and $y are lexicals contained in the outermost scope (probably a
file), while $z is a lexical available only in the while loop. When
used within the while loop, $x and $y refer to the same scalars
referred to outside of the while loop.
=head2 Use of Cmy
In all cases, the Cmy operator behaves as it does in Perl5, allowing
local variables that will not interfere with other variables, etc.
=head2 Dynamic Assignment
Dynamic assignment is the technical term given to the action performed
by Clocal in Perl5 and earlier versions. The value of a variable is
saved upon execution of the operator and restored when the current
scope ends.
There is no actual reason why dynamic assignment needs to be limited
to dynamic variables. This RFC strongly suggests that dynamic
assignment be enabled for lexical variables, as well. Programming
with all lexicals and occasional use of dynamic assignment can cover
many of the cases where dynamically-scoped variables are useful.
Note that Clocal will probably be renamed in Perl6.
=head2 Ambiguity
Several people have raised issues about possible ambiguities with this
idea, but they have all been instances of the same problem: the case
where an undeclared variable is used first within a block, then within
that block's containing scope. For example,
$cond = ...;
if ($cond) {
...
$color = "blue";
...
}
print "The color is $color\n";
The programmer expects the value of $color to be "blue" for the print
statement, but in fact $color is a brand-new, undefined, lexical
variable.
Translating this block from Perl5 to get the same behavior in Perl6 if
this RFC is adopted is straightforward and discussed in the
IMPLEMENTATION section.
There are two options for dealing with this construct in new Perl6
code:
=over 4
=item 1
Dubbed the "conservative" approach by Mark-Jason Dominus, this option
requires that the programmer disambiguate the situation by declaring
the variable with Cmy. Perl would produce a warning in this case to
the effect that, "A variable used within a block was used after that
block, but never declared or used before it. The enclosing scope
cannot see the same variable that exists within the enclosed block."
Alternatively, if this RFC is adopted, but nothing is done to alert
new Perl6 programmers about these possibly ambiguous cases, the
programmer would receive a "Use of undefined value" warning which
might suffice.
=item 2
In the "liberal" approach, perl can do what amounts to "inferring
declarations." To actually refer to it this way would be a
contradiction in terms, since a declaration is explicit, not inferred.
To implement the liberal approach, perl would detect all of the
undeclared variables used within a scope when it compiles that scope.
These variables would become available for use from the minute that
scope is entered. Thus, in the example above, $color is detected as
being a part of the enclosing scope before the interpreter ever enters
the if statement, and $color therefore refers to the same scalar in
both places.
=back
=head2 Variable declarations
This proposal
RFC 97 (v1) prototype-based method overloading
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
prototype-based method overloading
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 97
=head1 ABSTRACT
When I read the chapter on OO in the second edition camel book I
was saddened that C++ style method overloading was not explicitly
described. Ever hopeful, I wrote some quick code that I hoped would
do what I meant and discovered that it didn't. This document is
an attempt to remedy the situation.
=head1 SUMMARY
$frog_t = qs(frog);
sub listargs($){ print "One arg, $_[0]"}
sub listargs($$){ print "Two args, $_[0] and $[1]"}
sub listargs($$frog_t){ print "$_[0] and a frog $[1]"}
sub listargs { throw argsyntax, "odd arguments to listargs" }
my frog $k = new frog(type=tree);
listargs("franz","tree"); # prints "Two args..."
listargs("franz",$k); # prints "franz and ..."
listargs($k,"franz"); # throws an argsyntax error
=head1 DESCRIPTION
It it now possible to define two subroutines with the same
name but different interfaces without error. Perl will puzzle
out which one to call in a given situation based on lexical
information available in the program text.
Defining two subroutines with both the same name and the same calling
interface is undefined and may be an error. This may change.
No coercion protocol is defined at this time.
This document will be updated as a protocol for coercing
function calls with arguments that don't explicitly match is
developed, such as having a method name (which is now
distinct from a method, but still a strong grouping characteristic)
have a "coercion" method associated with it which would
indicate what to do if no prototypes matched.
For now, for the greatest ease
for implementors, calls to method Cfoo that exactly match none of the
prototypes of defined subroutines named Cfoo
will fall through to a Cfoo with no prototype, should one exist.
Programmers using this feature are advised to include a full coercion
system into their unprototyped methods, when writing in a strongly typed
environment.
=head1 IMPLEMENTATION
At compile time, the keys in the big hash (be it global or per-package
or per-class) that holds the mapping from the names of the classes
to their coderefs is extended to include the prototype as part of the
name of each method. The nature of this extension is beyond the
scope of this document.
=head1 REFERENCES
RFC 57: Subroutine prototypes and parameters
RFC 61: Interfaces for linking C objects into perlsubs
RFC 75: first class interface definitions
Programming Perl, 2ed
Re: RFC 97 (v1) prototype-based method overloading
On 14 Aug 2000, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
prototype-based method overloading
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 97
=head1 ABSTRACT
When I read the chapter on OO in the second edition camel book I
was saddened that C++ style method overloading was not explicitly
described. Ever hopeful, I wrote some quick code that I hoped would
do what I meant and discovered that it didn't. This document is
an attempt to remedy the situation.
=head1 SUMMARY
$frog_t = qs(frog);
sub listargs($){ print "One arg, $_[0]"}
sub listargs($$){ print "Two args, $_[0] and $[1]"}
sub listargs($$frog_t){ print "$_[0] and a frog $[1]"}
sub listargs { throw argsyntax, "odd arguments to listargs" }
my frog $k = new frog(type=tree);
listargs("franz","tree"); # prints "Two args..."
listargs("franz",$k); # prints "franz and ..."
listargs($k,"franz"); # throws an argsyntax error
=head1 DESCRIPTION
It it now possible to define two subroutines with the same
name but different interfaces without error. Perl will puzzle
out which one to call in a given situation based on lexical
information available in the program text.
Defining two subroutines with both the same name and the same calling
interface is undefined and may be an error. This may change.
No coercion protocol is defined at this time.
This document will be updated as a protocol for coercing
function calls with arguments that don't explicitly match is
developed, such as having a method name (which is now
distinct from a method, but still a strong grouping characteristic)
have a "coercion" method associated with it which would
indicate what to do if no prototypes matched.
For now, for the greatest ease
for implementors, calls to method Cfoo that exactly match none of the
prototypes of defined subroutines named Cfoo
will fall through to a Cfoo with no prototype, should one exist.
Programmers using this feature are advised to include a full coercion
system into their unprototyped methods, when writing in a strongly typed
environment.
=head1 IMPLEMENTATION
At compile time, the keys in the big hash (be it global or per-package
or per-class) that holds the mapping from the names of the classes
to their coderefs is extended to include the prototype as part of the
name of each method. The nature of this extension is beyond the
scope of this document.
=head1 REFERENCES
RFC 57: Subroutine prototypes and parameters
RFC 61: Interfaces for linking C objects into perlsubs
RFC 75: first class interface definitions
Programming Perl, 2ed
--
ask bjoern hansen - http://www.netcetera.dk/~ask/
more than 70M impressions per day, http://valueclick.com
Re: RFC 98 (v1) context-based method overloading
yOn 14 Aug 2000, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
context-based method overloading
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 98
=head1 ABSTRACT
The other way C++ allows you to overload a named function is
by return type. This document is a companion piece to
a similarly named one about protoypes. It replaces old Perl's
"wantscalar" and "wantarray" kluges, which can now be deprecated,
with a cleaner interface allowing decisions which are possible to
make at compile time to be made then.
=head1 DESCRIPTION
Defining multiple subroutines with both the same name and the same calling
interface that explicitly return items of differing types is now
allowed. subject to the following:
=over
=item compile-time
the return-type expectation of all method calls meaning to take advantage
of this feature must be clear from explicit type tags available at compile time.
=item what constitutes a context?
We are familiar with "scalar context" and "array context" from perl5 and
previous. Perl6 gives us user-defined contexts as well as user defined
types or all sorts. Any unique string can be a context, for the purposes
of context-based method overloading, and Perl will attempt to guess a
reasonable base class for the given "context." Use of undeclared context
specifiers will of course generate warnings.
=item interaction with prototype-based and traditional overloading
A traditional perlsub may be considered the simultaneous
definition of two routines,
C$ sub(PROTO){body} and
C@ sub(PROTO){body}.
It is now possible to differentiate between these two explicitly.
=item guaranteed sane values
The return context is considered before considering the types of the
arguments, and in the case of no exact match, the fallback is to a
default method defined to work in the given context rather than to
the default method for the name, should one exist.
=item specification incomplete
Further points to discuss and agree on include the relation of this
mechanism to inheritance, and multiple inheritance, and the meta-alteration
of all aspects of the mechanism.
=back
=head1 IMPLEMENTATION
At compile time, the keys in the big hash (be it global or per-package
or per-class) that holds the mapping from the names of the classes
to their coderefs are further extended to include,
as well as the prototype,
the declared type of the return values, when specified,
as part of the
name of each method.
=head1 REFERENCES
RFC 21: Replace Cwantarray with a generic Cwant function
RFC 57: Subroutine prototypes and parameters
RFC 61: Interfaces for linking C objects into perlsubs
RFC 75: first class interface definitions
--
ask bjoern hansen - http://www.netcetera.dk/~ask/
more than 70M impressions per day, http://valueclick.com
Re: RFC 97 (v1) prototype-based method overloading
"ABH" == Ask Bjoern Hansen [EMAIL PROTECTED] writes:
=head1 ABSTRACT
When I read the chapter on OO in the second edition camel book I
was saddened that C++ style method overloading was not explicitly
described. Ever hopeful, I wrote some quick code that I hoped would
do what I meant and discovered that it didn't. This document is
an attempt to remedy the situation.
=head1 SUMMARY
$frog_t = qs(frog);
sub listargs($){ print "One arg, $_[0]"}
sub listargs($$){ print "Two args, $_[0] and $[1]"}
sub listargs($$frog_t){ print "$_[0] and a frog $[1]"}
sub listargs { throw argsyntax, "odd arguments to listargs" }
Please do not do this.
It is a mess.
Action at a distance.
There are otherways to solve the same problem.
Why would anyone want to select a different method based upon the arguments.
The calling routine can easily dispatch differently.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 98 (v1) context-based method overloading
It will run faster, because it doesn't have to evaluate
the want(). (97,98) doesn't invalidate the current way of doing
things, it just gives a new way. And in syntax that is currently
erroneous.
Nathan Wiger wrote:
And what will aSub decide is it's context?
@foo = (1, 2, 3, aSub)
If I have to write scalar(aSub) then I see no point in this RFC.
What is it now? is
$ perl -le 'sub A() {wantarray?"array":"scalar"}; @foo = (1,2,3,A); print @foo'
123array
That would be array context.
And why shouldn't the caller decide? What is the gain in having perl
do the dirty work.
I agree. I don't see any reason to have to define 2 subs:
@ sub mysub {
# whole bunch of stuff happens
return @array;
}
$ sub mysub {
# same stuff that happens above happens here too
return $scalar;
}
Instead of just one:
sub mysub {
# whole bunch of stuff happens
if ( want 'ARRAY' ) {
return @array;
} else {
return $scalar;
}
}
This doesn't make any sense to me, I don't see any win here. Not being
mean, just being honest.
-Nate
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
Re: RFC 90 (v1) Builtins: zip() and unzip()
In message [EMAIL PROTECTED] Graham Barr [EMAIL PROTECTED] wrote: On Fri, Aug 11, 2000 at 03:30:28PM -, Perl6 RFC Librarian wrote: In order to reverse this operation we need an Cunzip function: @zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6) @unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6]) Is unzip used that often ? I wondered the same thing. As far as I can tell from a quick perusal of my copy of "Introduction to Functional Programming" there isn't a direct inverse of zip in Miranda. Of course if the array slicing RFC goes through you could always extract the original lists from a zipped list using array slices. =head1 IMPLEMENTATION The Czip and Cunzip functions should be evaluated lazily. lazily ? why, no other operator does by default (I am asuming here) Currently... I thought one idea for perl6 was to make more things use iterators instead of creating large temporary lists. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...I'm so close to hell I can almost see Vegas!
Re: RFC 90 (v1) Builtins: zip() and unzip()
Damian Conway [EMAIL PROTECTED] writes: Just to point out that the standard CS term is "merge". `merge' produces a list of items from 2 (or more) lists of items; `zip' produces a list of pairs (or tuples) of items from 2 (or more) lists of items. So in a language like Haskell which uses square brackets for lists and round for tuples (and `==' for equality, etc.): merge [1,2,3,4],[5,6,7,8] == [1,5,2,6,3,7,4,8] and zip [1,2,3,4],[5,6,7,8] == [(1,5),(2,6),(3,7),(4,8)] (note: `merge' is often also used to denote producing a list which respects ordering; then the above merge would produce [1,2,3,4,5,6,7,8]). [...] It's called `zip'. Really. -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 90 (v1) Builtins: zip() and unzip()
Ariel Scolnicov wrote: Damian Conway [EMAIL PROTECTED] writes: Just to point out that the standard CS term is "merge". `merge' produces a list of items from 2 (or more) lists of items; `zip' produces a list of pairs (or tuples) of items from 2 (or more) lists of items. So in a language like Haskell which uses square brackets for lists and round for tuples (and `==' for equality, etc.): merge [1,2,3,4],[5,6,7,8] == [1,5,2,6,3,7,4,8] and zip [1,2,3,4],[5,6,7,8] == [(1,5),(2,6),(3,7),(4,8)] This brings up an interesting question... which behaviour would we prefer? Currently the RFC defines zip() as producing a flat list, rather than a list of references to arrays. Of course, you can always say: $haskell_zip = partition (zip @^listOfLists, scalar @^listOfLists); which is why I figured the flat-by-default version would be more useful. If we created the partitioned version by default, then the other version would be: $haskell_merge = map @^, @listOfLists; which seems a little harder to evaluate lazily (for an individual item in a tuple, that is--evaluating a whole tuple lazily would be straightforward). Assuming that the current definition remains, 'merge' does seem more appropriate (and less offensive to the 'functionally challenged' ;-)
Sublist wrapup: MLC
The multiline comments sublist was due to expire on the 10th (a few days ago). It's now time to perform the wrapup and close the sublist. The chair was Michael Mathews, who I'd now like to ask to present a summary of the sublist's discussion to us, and tell us about the status of the multiline comment RFC (RFC 5). This is *not* an opportunity for further discussion on the -language list. If RFC 5 has been frozen or withdrawn, you're too late, and you should have been on the sublist :P K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Fwd: Sublist wrapup: unlink
The unlink sublist was due to expire on the 12th (a few days ago). It's now time to perform the wrapup and close the sublist. The chair was Nathan Wiger, who I'd now like to ask to present a summary of the sublist's discussion to us, and tell us about the status of the unlink RFC (RFC 29). This is *not* an opportunity for further discussion on the -language list. If RFC 29 has been frozen or withdrawn, you're too late, and you should have been on the sublist :P K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 65 (v1) Add change bar functionality to pod
On Tue, Aug 08, 2000 at 07:44:11PM -, Perl6 RFC Librarian wrote: =head1 TITLE Add change bar functionality to pod =head1 VERSION Maintainer: Dan Sugalski [EMAIL PROTECTED] Date: August 08, 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 65 I don't think this is a language issue. However, I don't believe there's a -doc working group yet, either. Is it time for a -doc group to form? K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
RFC 70 (v2) Allow exception-based error-reporting.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Allow exception-based error-reporting. =head1 VERSION Maintainer: Bennett Todd [EMAIL PROTECTED] Date: 8 Aug 2000 Last-Modified: 12 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 70 =head1 ABSTRACT Allow full implementation of Fatal.pm, for programmers who prefer exceptions for error reporting. =head1 DESCRIPTION Perl has traditionally reflected the Unix syscall and library tradition for error reporting: errors are indicated by otherwise-impossible return values, which must be checked for explicitly, lest system error events be ignored. Some programmers prefer to have errors print a message and exit with non-zero status, by default, rather than having to always code " || die ...". In perl5 this has proven elusive of implementation. Fatal.pm has been the attempt made to date, and it suffers from two problems. One can be fixed with further development: it should have various lists of builtins available, e.g. :io, :system, :all for including all calls affecting I/O, all system calls of any sort, and all calls that can have error returns. If these were a success, then the requested category could also be posted into a testable variable, allowing module authors who wished to to automatically support this functionality as well. But Fatal.pm development stalls out early, because some builtins, which report testable error conditions, cannot be wrapped. A conspicuous example is print(). =head1 IMPLEMENTATION Ensure that every perl builtin that can return an error, can be wrapped. I don't know whether this is purely an implementation issue (and so lies solely in the domain of perl6-internals) or whether any programmer-visible changes may be necessary to allow this (justifying posting to perl6-language). =head1 REFERENCES Fatal.pm, as included with recent perls. Error.pm, available from CPAN, and cited by RFC 63: if this proposal should carry, then Fatal.pm will see some very active development, and if RFC 63 should also prevail, then Fatal's development should be guided by RFC 63/Error.pm. RFC 80 Proposes a taxonomy for exception objects; should it prevail, it should guide the structure of exceptions thrown when Fatal.pm gets worked on.
RFC 89 (v2) Controllable Data Typing
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Controllable Data Typing =head1 VERSION Maintainer: Syloke Soong [EMAIL PROTECTED] Mailing List: [EMAIL PROTECTED] Date: 10 Aug 2000 Last-Modified: 12 Aug 2000 Version: 2 Number: 89 =head1 ABSTRACT Provide a choice for a programmer to define non-convertible and semi-convertible variables with explicit data-types. =head1 DESCRIPTION Current intelligence and flexibility of Perl variables are extremely indispensable. However at times this feature is also extremely inconvenient. As an example, character string "007" is often mistaken as int 7. So that concatenation of a variable strings "001999", "." , "03" to form an output filename could, unless with more extensive treatment, form a filename of 1999.3 instead. Attempts at storing into a hash with the key "007" or " 7" rather than 7 is a trying experience. Not to mention attempts at reading a hash using similar keys. A compromise between dead-bolted types and liberal types is struck through constrained and controllable typing. There is a hint of polymorphic behaviour. =head1 IMPLEMENTATION Retain current flexibility of Perl liberal variables. Provide a new form of declaring variables: scope cast-type $varname:constraint; Valid declarations would be: my $varname; my (var-list); my cast-type $varname; my cast-type (var-list); my $varname:constraint; my (var-list):constraint; my cast-type $varname:constraint; my cast-type (var-list):constraint; my $varname:(constraint-list); my (var-list):(constraint-list); my cast-type $varname:(constraint-list); my cast-type (var-list):(constraint-list); =head2 Simple examples my $old; my int $k; my varchar $str; my char(5) $zip; use CGI; my CGI $q; my Net::SNPP ($pg, $pq); my int $a = 3.9; my int $ceil = 3.9 + 0.5; my int $i = 'hello'; my double $f1 = 'hello'; my double $f2 = $a; $old is the declaration of a liberal type; $a evaluates to int 3; $ceil evaluates to int 4; $i evaluates to int 0; $f1 evaluates to double 0.; $f2 evaluates to double 4.; =head2 Constant constraint A constant confered by the keyword const creates a final value; That value stays immutably the same throughout the scope of its existence. my $a1:const; my int $k1:const; my varchar $str1:const; my $a21:const = '023'; my $a22 = 3 + $a21; my $a23 = 3.$a21; my int $k21:const = '023'; my int $k22:const = 23; my varchar $str21:const = 3; my char $str22:const = 3; my char(1) $str22:const = 3; my Net::SNPP ($pg, $pq):const; my Net::SNPP ($pr, $ps):const = new Net::SNPP ; my Net::SNPP ($pt = $pu, $pv):const = new Net::SNPP ; use strict(constcroak); $str22 = 'hello'; $a1, $k1, $str1 are henceforth constantly null liberal, int and varchar respectively; $$a21 acquires constant value of char(3) '023'; $a22 acquires variable value of liberal-type 26; $a22 acquires variable value of liberal-type 3023; $k21, $k22 both acquire constant values of int 23; $str21, $str22, $str23 all acquire variable values of char(1) 3; $pg and $pq henceforth vainly reference null objects of Net::SNPP; Whereas $pr, $ps, $pv usefully and loyally reference separate objects of Net::SNPP; $pt and $pu both reference the same Net::SNPP object constantly. The strict directive, default being noconst (disregard any harassment on a const), is set to croak when an attempt to change the value of constant $str22 is made. Use of use strict(constdie); should also be an option. =head2 Constraint lists my $id:(double,int); my int $id1:(double,int) = 1.7; my int $id2:(varchar, double) = 2.6; my int $id3:(varchar, double, int) = 2.6; my char $c1 = 'a'; my char $c2:char = 'a'; my char $c3:(char) = 'a'; my $id4:(varchar, double, int) = 2.7; my $id5:(varchar, double, int) = 3; my $id6:(varchar, double, int) = 'Fatrick Perlland'; $id is constrained to behave either as double or int; $id1 is constrained to behave either as double or int, but int casting initialises it to (double,int) 1; $id2 and $id3 are similar declarations such that a cast not found in the constraint list will be spontaneously added to the constraint list; Both acquires (varchar, double) value of 2.6; Declarations of $c1, $c2, $c3 are all equivalent forms. Declaration of $c1 follows the rule of spontaneous appending a cast to its constraint list. $id4, $id5, $id6 are constrained to behave either as varchar, double or int; $id4 acquires value of (varchar, double, int) 2.7; $id5 acquires value of (varchar, double, int) 3; $id6 acquires value of (varchar, double, int)
Re: RFC 83 (v1) Make constants look like variables
On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands. Yes, the syntax is often unweildy -- but IMHO
that's because when one marries the idea of constants to complex data
structures and references, the world becomes an unweildy place.
On the other hand, many of the uses of constants are better-satisfied
by having hidden or inaccessible members. If constants were limited
to `core' perl data types (scalars, lists, arrays and hashes) and
*completely* freezing the data element, that'd be enough for me. I lust
to be able to do things like
if ( $HOME =~ /indiana/ ) {
local $::PI : const = 3; do_trig();
} else {
local $::PI : const = 3.14159...; do_trig();
}
(I'm from Indiana and claim right to use that joke without being
insulting). Constants are good, and I'm damned tired of fixing code like
if ( $PI = 3 ) {
# We're not in Kansas any more, Toto.
}
Constants have a place, and belong in perl.
Now, one may argue that my suggestion was too flexible or too broad.
But the initial proposal left an awful lot of gray areas. If my proposal
is felt to be too unweildy, I don't have a problem with that. Let's
either
o decide where to draw the line, define it cleanly, and say
that more complex usage is better done with objects; or
o permit both complex constants and object-based manipulations
on the practice that TMTOWTDI.
I lean towards the latter (complex constants) myself, but wouldn't
go off and storm the barricades to get it. On the other hand, I
*would* campaign strongly for constant scalars, lists, arrays, hashes
and refs. If the only way to get them meant `completely constant',
ie, no addition or removal or members, no re-orderings, etc, that's
fine -- composition of complex constants with complex vars would let
one do most of what was suggested in my longer posting, and I'd be
happy to say the odder features should be done via object methods.
Re: RFC 83 (v1) Make constants look like variables
I agree that constants deserve a prominent place in Perl, as they offer
constaint which can be beneficial to programmers. Sometimes its nice to know
that I mistakenly tried to treat a static variable as dynamic.
I disagree with "const" as it's verbose; I'd rather see something like
$pi=|3.14128 or something similar.
I've noted a few messages here with statements like "it looks like C++" and
"I hated that in Pascal" and so on. If we restricted ourselves to constructs
not found in other languages, there would be no Perl as we know it today.
Larry freely admits he borrowed constructs and techniques from many
languages.
There are many logical reasons for and against the RFC's here, but saying
"it looks like c so it doesn't make it for me" is a weak argument at best.
-WQ
From: Steve Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], Steve Simmons [EMAIL PROTECTED],Larry Wall
[EMAIL PROTECTED], Mike Pastore [EMAIL PROTECTED],Jeremy
Howard [EMAIL PROTECTED]
Subject: Re: RFC 83 (v1) Make constants look like variables
Date: Mon, 14 Aug 2000 12:57:14 -0400
On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands. Yes, the syntax is often unweildy -- but IMHO
that's because when one marries the idea of constants to complex data
structures and references, the world becomes an unweildy place.
On the other hand, many of the uses of constants are better-satisfied
by having hidden or inaccessible members. If constants were limited
to `core' perl data types (scalars, lists, arrays and hashes) and
*completely* freezing the data element, that'd be enough for me. I lust
to be able to do things like
if ( $HOME =~ /indiana/ ) {
local $::PI : const = 3; do_trig();
} else {
local $::PI : const = 3.14159...; do_trig();
}
(I'm from Indiana and claim right to use that joke without being
insulting). Constants are good, and I'm damned tired of fixing code like
if ( $PI = 3 ) {
# We're not in Kansas any more, Toto.
}
Constants have a place, and belong in perl.
Now, one may argue that my suggestion was too flexible or too broad.
But the initial proposal left an awful lot of gray areas. If my proposal
is felt to be too unweildy, I don't have a problem with that. Let's
either
o decide where to draw the line, define it cleanly, and say
that more complex usage is better done with objects; or
o permit both complex constants and object-based manipulations
on the practice that TMTOWTDI.
I lean towards the latter (complex constants) myself, but wouldn't
go off and storm the barricades to get it. On the other hand, I
*would* campaign strongly for constant scalars, lists, arrays, hashes
and refs. If the only way to get them meant `completely constant',
ie, no addition or removal or members, no re-orderings, etc, that's
fine -- composition of complex constants with complex vars would let
one do most of what was suggested in my longer posting, and I'd be
happy to say the odder features should be done via object methods.
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: RFC 83 (v1) Make constants look like variables
Steve Simmons writes: : On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote: : : Please, please, please, PLEASE, let us not replicate the debacle that is : C++'s const modifier! : : It doesn't feel like a debacle to me, it feels like it put the control : in the programmers hands. Yes, the syntax is often unweildy -- but IMHO : that's because when one marries the idea of constants to complex data : structures and references, the world becomes an unweildy place. Hmm, well, we'll certainly have constants of some sort or another. I don't think Damian needs to worry about me making Perl look like C++. I've also grown to detest the fact that every other word in a typical C++ program is "const". My inclination at this point is make certain things constant by default (such as the insides of a complex constant, and the parameters to a subroutine), and then have a way of "undeclaring" constancy if you really want it. It would perhaps be considered bad form to vary someone else's constants. (Outside of Indiana.) Larry
English language basis for throw
Dan Sugalski wrote: perl cribs from english as much as any other language, spending some time to get names that fit well makes perfect sense, especially since most of the perl programmers that start using this won't be coming with huge gobs of experience from languages that already do it. I find "throw" to be a perfectly good synonym for "raise" an exception. The english language equivalent is a piece of steel machinery, when it breaks while running, which is said to "throw a rod" or "throw a bolt" depending of course on the nature of the broken item that comes flying out of the mechanism at dangerous and possibly inventor-fatal speeds. I find it preferable to "die" which has always struck me as morbid, even if it does echo the equally objectionable unix "kill." "Killing to send a signal" sounds like La Casa Nostra or president Clinton flying over Bosnia. (Opposed to, for instance, LBJ, who killed because he got residuals on the damn bombs) (my source is a vietnam-era veteran hitchhiker I picked up while on summer vacation this year) Because of the MTOWTDI nature of the Perl experiment, eventually there will be perl programmers trying to make sense of C++ and Java(?) nomenclature in which one throws exceptions and catches them with exception handlers. This language (throw, catch) seems natural and I have seen no viable alternative on this mailing list (although it is very possible that it was at the bottom of a thread I abandoned after reading the first ten on-topic messages.) and I have begun using it in "perl6 example code" included in my RFC submissions. -- David Nicol 816.235.1187 [EMAIL PROTECTED] :wq
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]
draft RFC: example of Clazy keyword affecting a list context
tie %h A_DATABASE_RETURNING_OBJECTS, yadda, yadda, yadda;
for (grep {$h{$_}-STATE eq 'NY'} keys %h){
$h{$_}-send_advertisement();
};
We want "keys" to return an RFC24 "lazy list" when it is
compiler-obvious that it is safe to do so, meaning:
--- the argument hash is never part of an L-value within
the scope where the return value will be used
--- the context is marked as accepting lazy lists
--- more? Neverpart of an L-value within a side effect...
--- the hash is marked iterator-safe, meaning that it is
not vulnerable to deadlocks during iteration.
The question is, how do we tell the compiler that "for" in this
example requires a complete list, because the Csend_advertisement
method changes the value of its instance?
Do all class methods start marking themselves as to whether they
change their obejcts or not? This seems too complex.
What if adding laziness to a list context was up to the programmer
and passed through functions that can support it:
for (lazy(grep {$h{$_}-STATE eq 'NY'} keys %h)){
$h{$_}-send_advertisement();
};
would cause a lazy list is passed to Cfor, and increment of
the object's "letters_sent_total" field might break the iteration.
for (grep {$h{$_}-STATE eq 'NY'} lazy(keys %h)){
$h{$_}-send_advertisement();
};
causes a lazy list to be passed to our filter function Cgrep, saving
us from allocating the entire Ckeys array. CGrep is still in
the default busy context, so it returns a busy array, which Cfor
can iterate over safely.
Tom Hughes wrote:
In article [EMAIL PROTECTED], "David L. Nicol"
[EMAIL PROTECTED] writes:
Hmmm. Not all external hash implementations support multiple
iterators, I don't know which ones do. If we had explicit
access to element-nextkey() that would make things more
complex for user.
The first thing is that I don't expect iterators to be very user
visible - certainly not to that kind of extent. As to external
implementations that don't support multiple iterators, that might
be a bit of a problem but I think it can be worked round.
I rely on keys(%h) to be free and clear of any issues %h
might have if it is assigned to during the iteration, and know
to watch for this when I'm writing code that will modify the
data while iterating it: I push the keys of all the new yorkers
to an array during the iteration, then I go through that list
and send them their letters and increment their letters-sent
fields.
That is a bit of an issue I guess... I'll have to think about
that a bit.
Its been so long that I don't see not having multiple iterators
as a problem.
That isn't really the main thrust of what I'm thinking about
as it was more something I was taking for granted would be dealt
with as it has always been a "we must fix that some day" thing
on p5p.
What would the syntax look like? I'll gladly look over your proposal
if you'd like me to, before you make it into an RFC
I'm not planning an RFC at the moment as what I'm thinking about
is more an implementation detail relating to a number of current
language suggestions. I may do something in due course though.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
Re: RFC 89 (v2) Controllable Data Typing
At 11:15 AM 8/14/00 -0700, Nathan Wiger wrote: I'm going to actually ask for a new mailing sublist, probably called -object, on which this should be discussed. There's lots and lots and lots and lots of details to work out. It might be best to wait a bit and see how the proposed internal representation settles down first. You may find a lot of this isn't actually necessary. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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)
How 'bout 100ns ticks from base date, stored in a 64-bit number? That We are going to have quads supported on all platforms, then? With software emulation of our own if nothing else is available? I wouldn't object, mind... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
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)
At 01:48 PM 8/14/00 -0500, Jarkko Hietaniemi wrote: How 'bout 100ns ticks from base date, stored in a 64-bit number? That We are going to have quads supported on all platforms, then? With software emulation of our own if nothing else is available? I wouldn't object, mind... I'd like to provide ints of that size, yes. Whether they're native (on, say, Alphas or SPARCs), faked by the compiler, or faked by perl is an open question, but I would like them in. This might end up in BigInt format instead of plain int if the platform integers are too small, but that's OK, I think. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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
Nick Ing-Simmons wrote: Ed Mills [EMAIL PROTECTED] writes: There are many logical reasons for and against the RFC's here, but saying "it looks like c so it doesn't make it for me" is a weak argument at best. I don't think anyone made that argument - they have all been "I hate that in ..." type comments. You forget... There have been numerous cases of people saying things like "that's what Python [or Java] calls those functions, so we should call them something else." -- John Porter
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, 14 Aug 2000, Nick Ing-Simmons wrote: Jonathan Scott Duff [EMAIL PROTECTED] writes: On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: =head1 TITLE Maintain internal time in Modified Julian (not epoch) There has to be _an_ epoch - even Caesar started somewhere... Julian Date is measured (roughly) from earliest astronomical observations that we have available to us. MJD is JD with the slowly varying bit removed (and correcting for the 0.5 day so that MJD starts at midnight rather than midday). 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) IEEE 'float' (the short one) has about 6 places (24 bit mantissa). double has many more. But even I don't think using years as the "unit" is right thing to do. Seconds is my favourite... Just to clarify, MJD is days not years. A 32-bit double preicision number is usually adequate -- although have not thought about nano seconds! -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 83 (v1) Make constants look like variables
John Porter [EMAIL PROTECTED] writes: Nick Ing-Simmons wrote: Ed Mills [EMAIL PROTECTED] writes: There are many logical reasons for and against the RFC's here, but saying "it looks like c so it doesn't make it for me" is a weak argument at best. I don't think anyone made that argument - they have all been "I hate that in ..." type comments. You forget... There have been numerous cases of people saying things like "that's what Python [or Java] calls those functions, so we should call them something else." You may be right - though as I recall those were "that's what X calls those functions, ours don't work the same so we should call them something else" My point was if experienced folk don't like something somewhere else we should think twice before borrowing it. The _names_ don't matter much at this stage - Larry can change them but if "making things const like C++" is a bad idea then it is a bad idea - A midden by any other name would smell as foul. -- Nick Ing-Simmons
Re: RFC 90 (v1) Builtins: zip() and unzip()
Nathan Wiger wrote: "David L. Nicol" wrote: These things sound like perfectly reasonable CPAN modules. What's the block prevenenting their implementation w/in the perl5 framework? Jeremy and I are working on a general purpose matrix/unmatrix function that may well be core-worthy. This would allow arbitrary reshaping of 2d (Nd?) arrays into any form imaginable. Actually, I still remain to be convinced that RFC 81 (Lazily evaluated list generation functions) isn't already this generic tool (when used as an index to another list). When you've got some examples of using your proposed 'reshape' (or whatever it'll be called), I'll see what the same code looks like with RFC 81 notation... However, I would probably argue that zip/unzip/merge/unmerge/whatever go into a module (Math::Matrix?) since they'll probably just be specialized calling forms of matrix/unmatrix. I think the trend is to put a lot of formerly-core functions and features in modules, especially if subs get fast enough (and it sounds like they're going to). Definitely, if the generic foundation for them (lazily generated lists, reshape, ...) is there. But to answer Nick's question, the reason they're not in Perl 5 in this way at the moment is that Perl 5 doesn't provide the foundation required for them. Although it's easy enough to write a zip or partition function in Perl 5, because it can't be evaluated lazily and would therefore be useless for any real numeric programming. Also there's no use in having just array reshaping functions if the rest of the baggage required to avoid explicit loops isn't in the language. In general, if array notation (i.e. working with lists without explicit loops) isn't reliably efficient, I would always use explicit loops instead (since the loss of clarity is more than outweighed by the increased speed and lower memory use).
Re: RFC 89 (v2) Controllable Data Typing
=head1 TITLE Controllable Data Typing =head1 VERSION Maintainer: Syloke Soong [EMAIL PROTECTED] Mailing List: [EMAIL PROTECTED] ... Retain current flexibility of Perl liberal variables. Provide a new form of declaring variables: scope cast-type $varname:constraint; ... =head2 Constant constraint A constant confered by the keyword const creates a final value; That value stays immutably the same throughout the scope of its existence. I don't think this RFC is the place to try and cover all of the 'constraints' that might be in perl 6. Sure, this RFC may as well be the one to formalise the notation that attributes of variables are defined in this way, but also trying to enumerate and describe them would make this RFC very bloated. On the 'const' issue specifically, there's already an RFC for that (RFC 83). Syloke--if you really want to incorporate this RFC then please let me know, and I'll send you all of the suggested changes I've received in feedback to RFC 83. However, I think it would be much easier if we kept discussion of the actual 'constraints' in separate RFCs, allowing debate on each issue to be kept separate. Furthermore, using the term 'constraint' is misleading--I think 'attribute' is better. Another to-be-proposed attribute is 'sparse', which gives Perl information about how to store a list. And then of course there's character set type attributes (eg 'utf8')... These are not constraints, but they all use the same notation. Finally, the attribute notation needs a way of taking parameters. For instance, the 'sparse' attribute needs a default value, and an optional 'sparsity index'. We need syntax that allows something like: my int @sparse_array : sparse(0,0.99) = ((0) x 5 , 1);
Re: RFC 89 (v2) Controllable Data Typing
RFC 89 forms the basis of another RFC I'm forwarding very soon. Though I realise this broadens the scope of the RFC, I needed the constant thing defined in the manner of a constraint for my next one coming. Both of us are in agreement. It's a constraint through the use of attributes. By default, Perl references/variables have liberal data-types. I wish to provide attributes through which we could constrain the liberality of those data-types. I want to use the word constraint because I want to reflect the constraining action. If it fits in tidier into the glossary I could update to call it - constraining attributes. Quite a mouthful. Let me forward this next RFC first for everyone's kind perusal, after which I will be very enthusiastic to work with you to over-ride these RFCs. - In plain, the sane in Maine stays mainly for the rain. [EMAIL PROTECTED] on 08/14/2000 07:07:00 PM To: Syloke Soong/Americas/NSC@NSC cc: [EMAIL PROTECTED]@Internet Subject:Re: RFC 89 (v2) Controllable Data Typing I don't think this RFC is the place to try and cover all of the 'constraints' that might be in perl 6. Sure, this RFC may as well be the one to formalise the notation that attributes of variables are defined in this way, but also trying to enumerate and describe them would make this RFC very bloated. On the 'const' issue specifically, there's already an RFC for that (RFC 83). Syloke--if you really want to incorporate this RFC then please let me know, and I'll send you all of the suggested changes I've received in feedback to RFC 83. However, I think it would be much easier if we kept discussion of the actual 'constraints' in separate RFCs, allowing debate on each issue to be kept separate. Furthermore, using the term 'constraint' is misleading--I think 'attribute' is better. Another to-be-proposed attribute is 'sparse', which gives Perl information about how to store a list. And then of course there's character set type attributes (eg 'utf8')... These are not constraints, but they all use the same notation. Finally, the attribute notation needs a way of taking parameters. For instance, the 'sparse' attribute needs a default value, and an optional 'sparsity index'. We need syntax that allows something like: my int @sparse_array : sparse(0,0.99) = ((0) x 5 , 1);
Sublist wrapup: unlink
No posts we recorded on the mailing list perl6-language-unlink, which was setup to discuss RFC 29. As such, the issue is assumed closed per the existing RFC 29. It will be frozen as-is. -Nate
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 02:28:29PM -0500, Jonathan Scott Duff wrote: 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 :-) You think you've got problems... I saw "mjdate" and thought that Mark Jason Dominus was involved. But yes, this is an internals issue. K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
RFC 101 (v1) Handlers and Pseudo-classes
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Handlers and Pseudo-classes
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 101
Status: Developing
=head1 ABSTRACT
Currently, there is no way to have multiple methods or modules for
dealing with events without significant contortions:
$data = $r1-get_data || $r2-stuff || $r3-func;
$r1-do_stuff(@vals) or $r1-do_this(@vals);
These simple cases can actually be tolerated. However, there are many
more complex cases which cannot be handled at all in Perl. These include
opening files only in certain directories, having methods decline or
partially handle requests, and so on.
This RFC proposes the idea of a Chandler, which is a special type of
class that is actually composed of one or more classes. Their operation
is very similar to Apache handlers: requests can be handled, declined,
or partially handled, without the top-level program having to know about
it.
=head1 DESCRIPTION
=head2 Overview
The concept of a Chandler is actually not that complex. In the
simplest case, it can be thought of as a type of abstraction:
sub open_it {
my $file = shift;
return open $file ||
HTTP::open $file ||
FTP::open $file;
}
Then, in your script, you would simply say:
$fileobject = open_it " $filename";
This gives you several benefits:
1. The internal handling of open_it can be changed
without having to update all your programs
2. Each operation can actually partially process
the request, if appropriate
2. Your program is easier to read and understand
From a Perl standpoint, these handlers work just like normal functions
and classes: they have methods, properties, inheritance, and so forth.
The only difference is that these handlers do not live in an external
file, but rather are assembled internally by Perl.
=head2 Basic Syntax
First, the examples assume that the reader is somewhat familiar with RFC
14. If not, it is recommended that you give it a quick read at
http://dev.perl.org/rfc/14.pod
There are several competing syntaxes that I have for this proposal. I've
provided the one that I think is the best, but this is open to
discussion.
The proposed syntax is to use a pragmatic style:
use handler 'http' = 'MyHTTP';
use handler 'http' = 'LWP::UserAgent';
This would assemble a Chandler called 'http' which could then be used
in functions in your program. This handler would be a pseudo-class that
inherits methods from CMyHTTP and CLWP::UserAgent, in that order.
So:
$fo = open http "http://www.yahoo.com" or die;
would call Chttp-open, consistent with the current Perl
implementation. The only difference would be that Chttp now tries to
call the Copen() method from CMyHTTP and CLWP::UserAgent. As such,
the above call would result in the following flow chart:
$fo http-openundef
^ | ^
| | |
| Does MyHTTP::open exist?|
|YES/ \NO |
| / \ |
| Try it Does LWP::UserAgent::open exist? |
| / \^ YES/ \NO |
|OK/ \UNDEF / /
--- -- Try it|
| / \ |
| OK/\UNDEF |
- -
Some highlights:
1. Each class's open() method is tried in turn.
2. If undef is returned, the next one in sequence
is tried.
3. If 'OK' (simply meaning 1 or some other true
value, like $fo) is returned, that is propagated
out and returned by the top-level handler.
4. All classes are tried until 'OK' is returned
or the last one is reached.
This allows you to easily chain classes and methods together with a
couple key benefits over an inline C||:
1. Each handler can partially handle the request,
but still return undef, deferring to the next
one in line.
2. The handlers can be reordered internally at-will
without the main Copen http code having to be
redone.
3. Different class open() methods can use internal
rules, such as "only open .com URLs", without
you having to put checks for this all over the
place in the top-level program.
Note that Copen() is the name of the method called on each class
because that is the name of the method called on the Chttp handler.
If:
http-bob(@stuff);
was called, then CMyHTTP::bob and CLWP::UserAgent::bob would be
attempted, in that order.
=head2 Automatic Handler Registration
When a class is imported, it should be able to automatically register as
a
RFC 102 (v1) Inline Comments for Perl.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Inline Comments for Perl.
=head1 VERSION
Maintainer: Glenn Linderman [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 102
=head1 ABSTRACT
Unlike many programming languages Perl does not currently implement
inline comments. This can be confusing/tedious to programmers. This
could be solved by adding a syntax to Perl 6 that would allow for inline
comments.
=head1 DESCRIPTION
Comments are important to programmers as a way of documenting their code
and for debugging purposes. Perl's comment syntax requires that
comments can only be placed at the end of a line, or on a separate line
(or lines). Sometimes it is desirable to place a comment (or comments)
within a line.
Perl currently uses the "#" character as an end-of-line comment
introducer (as do many other scripting languages). RFC 5 (multiline
comments) suggests as a possible promising syntax an introducer of the
form "#TOKEN", combining the perl concepts of "comment" and "here
document" for multiline comments.
It is felt that an inline comment syntax should leverage the existing
Perl comment concept ("#" introducer) and that the introducer and
terminator should look like a matched pair for ease of understanding.
=head2 Ideas from other languages
C/C++ use "/*" and "*/" as introducer/terminator for in-line and
multi-line comments. A different syntax was introduced in C++ for
end-of-line comments: "//".
Pascal uses "(*" and "*) as introducer/terminator for in-line and
multi-line comments. It has similar difficulties as C/C++ with
commenting out blocks of code.
Forth uses "(" and ")" as introducer/terminator for in-line and
multi-line comments, and "\" for end-of-line comments.
Basic doesn't support in-line or multi-line comments.
All the languages that use the same syntax for in-line and multi-line
comments suffer from confusion when a multi-line comment is used to
comment out a block of code containing in-line comments.
Implementations have historically varied within the language on how to
handle that situation.
=head2 Ideas for perl
An idea that produces a paired feeling would be to use one of the
paired character pairs, as in "#" and "#". I like this one best,
of the three paired character possibilities ("", "()", "{}") because
it is more closely related to the "#TOKEN" syntax suggested for
multi-line comments by RFC 5, thus also achieving a more Perlish feel,
when combined with that syntax.
An idea with obvious appeal to C/C++/Pascal programmers would be to
use "#*" as the introducer, and "*# as the terminator. This would
probably work as good as any.
=head2 Compatibility considerations
Because "#" has been used to mean comment, it seems that something
related to "#" should continue to be used to mean comment.
Use of a bare "#" as an in-line comment terminator would break
lots of existing practice, where people have used a variant number of
"#" characters to introduce comments of more or less importance, or
as a way of achieving "pretty" multi-line comments (example of such
next)
#
## This is a stand-out comment ##
#
Hence it seems some other character should be combined with "#" as an
in-line comment introducer, and used in reverse order (per
practice in other languages) as the comment terminator.
Because historically there is nothing to prevent a sequence such
as the following:
code # this is an end-of-line # comment
from appearing, this suggestion is not 100% compatible with perl5
syntax. However, such a sequence is relatively unlikely: I've never
seen one in any Perl code I've perused. By limiting this construct
to less than a single line, it limits the boundaries of confusion:
if "#" is found with the intended meaning of an end-of-line
comment introducer followed by a "" character, the highly probable
lack of the sequence "#" within the same line can be diagnosed with
a warning or error identifying exactly the line involved.
=head2 Discussion in perl6-language and perl6-language-mlc
There was some discussion of in-line comments in the
perl6-language and perl6-language-mlc lists. There wasn't a
consensus reached. The competing suggestion for in-line comments was
to define "qc/comment/" as a syntax that evaporates. I don't like
that syntax, because it looks more like code than comment, and doesn't
stand out to the eye as a comment when mixed within code:
$foo = qw/foo bar/ qc/eat me/;
It is not clear whether such syntax would be easily readable within all
forms of expressions, without operators, as shown in the above example,
vs
$foo = qw/foo bar/ #eat me#;
=head1 IMPLEMENTATION
Should be straightforward in the Perl parser/lexer.
=head1 REFERENCES
RFC 5 (multiline comments) see
RFC 103 (v1) Fix print $r-func and $pkg::$var precedence
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix print "$r-func" and $pkg::$var precedence
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 103
Status: Developing
=head1 ABSTRACT
Currently, attempting to use objects in a string context
yields garbage:
print "r is $r-func"; # "OBJ=HASH(0xef958)-func"
print "r is ", $r-func; # works, but clumsy
In addition, trying to dynamically assign to unnamed classes
is very difficult:
$pkg::$var = $val; # error
${"${pkg}::$var"} = $val; # works, but bleeech!
The precedence and parsing of these operators should be fixed to allow
these important operations.
=head1 DESCRIPTION
=head2 Printable objects
This should print out correctly:
$r = new Class;
print "$r-func";
This would make it consistent with hashrefs and arrayrefs, which already
work correctly in string contexts.
Note that both this RFC and RFC 49 propose changes that make an object's
debugging info hard to get to. The next version of RFC 49 will include
an operator for easily accessing that information. Please see it for
details.
=head2 Dynamic package names
Currently, assigning values to dynamically-created package names is,
frankly, and pain in the butt. Major. These should work in Perl 6:
$pkg = 'Class';
$var = 'DEBUG';
$pkg::$var = 1;
$subpkg = 'Special';
$class = $pkg . '::' . $subpkg;
require $class; # require Class::Special
Currently, the precedenence of :: vs. symbolic references does not allow
these operations.
=head1 IMPLEMENTATION
I'll leave that to the internals guys. :-)
=head1 REFERENCES
RFC 49: Objects should have builtin stringifying STRING method
Programming Perl, 2ed, for the ${"${pkg}::$var"} syntax
RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Maintain internal time in Modified Julian (not epoch) =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 14 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 99 Status: Developing =head1 ABSTRACT Currently, internal time in Perl is maintained via Ctime, in seconds since the UNIX epoch (01 Jan 1970 UTC). However, this is a very ancient approach and quite UNIX-centric. Perl 6 should maintain its internal clock source as the Modified Julian Date. =head1 DESCRIPTION The Modified Julian Date is a system-independent, universally recognized time source. It has several key advantages builtin, including: 1. The ability to do date arithmetic with simple math ops 2. It can be used to easily derive many other sources, including UTC and local time 3. It is platform and even computer-independent This RFC proposes several key changes to Perl 6's internal time- keeping: 1. Maintain time internally via Modified Julian Date (MJD) 2. Replace Ctime with Cmjdate, which will return MJD 3. Make all core time and date functions based off MJD =head1 IMPLEMENTATION The Ctime core function should be moved to an external module, such as CTime::Local or CUnix::Time. A core Cmjdate function should be added, which returns the Modified Julian Date. Its name was chosen to make it consistent with the new Cdate and Cutcdate functions described in RFC 48. =head1 REFERENCES RFC 48: Replace localtime() and gmtime() with date() and utcdate() Tim Jenness and Buddha Buck for their great links: http://www.jach.hawaii.edu/JACpublic/stardocs/sun67.htx/node217.html http://tycho.usno.navy.mil/systime.html http://tycho.usno.navy.mil/mjd.html
Re: RFC 65 (v1) Add change bar functionality to pod
skud [EMAIL PROTECTED] writes: I don't think this is a language issue. However, I don't believe there's a -doc working group yet, either. Is it time for a -doc group to form? [EMAIL PROTECTED] already exists; maybe it should be blessed as a Perl 6 working group as well? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
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 :-) Hey wait, you're both right! :-) The idea would be twofold: 1. time() would still return UNIX epoch time. However, it would not be in core, and would not be the primary timekeeping method. It would be in Time::Local for compatibility (along with localtime and gmtime). 2. mjdate() would return MJD. It _would_ be in core, and it _would_ be the internal timekeeping method. All of the new date functions would be designed to be based off of it. So, just to clarify: 1. The Perl 5 way in Perl 6: use Time::Local; $date = localtime time(); 2. The Perl 6 native way: $date = date mjdate(); Make sense? -Nate
RE: Unify the Exception and Error Message RFCs?
This seems like a good idea, to me. -Corwin From: Steve Simmons [mailto:[EMAIL PROTECTED]] IMHO trading six RFCs for two will greatly improve the chance of passing.
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On 14 Aug 2000, Russ Allbery wrote:
Nathan Wiger [EMAIL PROTECTED] writes:
The idea would be twofold:
1. time() would still return UNIX epoch time. However, it
would not be in core, and would not be the primary
timekeeping method. It would be in Time::Local for
compatibility (along with localtime and gmtime).
2. mjdate() would return MJD. It _would_ be in core, and
it _would_ be the internal timekeeping method. All
of the new date functions would be designed to be based
off of it.
snip
By comparison, who uses MJD? Practically no one. It's a theoretically
nice time scale, but outside of the astronomy community, how many people
even have any idea what it is?
In one of my previous posts I was simply suggesting that the Date object
(whatever it is) should have a method to return the internal format
(seconds, mjd, whatever) to allow for simple date arithmetic without
having to do anything more complicated. unix seconds and mjd both will
allow this.
This appears to be a proposal to replace a *very* well-known time base
with very well-known and commonly-used properties with a time base that
practically no one knows or currently uses just because some of its epoch
properties make slightly more sense. Unless I'm missing something
fumdamental here, this strikes me as a horrible idea.
Of course, "seconds since 1970" is only obvious to unix systems
programmers. "Number of days since XXX" is just as valid for someone
coming to the language from a different direction and at least has some
kind of basis outside of computing.
Unix's time representation format has no fundamental problems that aren't
simple implementation issues. Negative values represent times before 1970
just fine. The range problem is easily solved by making it a 64-bit
value, something that apparently we'd need to do with an MJD-based time
anyway. And everyone already knows how it works and often relies on the
base being consistent with their other applications.
MJD is doable with current perl 32bit doubles. I use it all the time in
perl programs and am not suffering from a lack of precision.
In fact RFC #7 ("Higher Resolution time values") suggests that the
concept of "number of seconds since epoch" will have to make room for
fractions of a second anyway.
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
Anyway, it doesn't matter; it's a lot more widely used than any other epoch, and epochs are completely arbitrary anyway. What's wrong with it? I think the "What's wrong with it?" part is the wrong approach to this discussion. Personally, I'm a 100% UNIX head. All I work on is UNIX (thank heavens). And that's all I even plan on using; after all, I'm a UNIX sysadmin. So, time() actually makes more sense to me than mjdate(), even though I proposed the RFC. That being said, what we need to say "is it possible UNIX might not be perfect?" (hard to imagine, true... :-). More specifically, "is there something that would work better for putting Perl in Palm pilots, watches, cellphones, Windows and Mac hosts, *plus* everything else it's already in?" Is Perl currently using different epochs on different platforms? No, but currently Perl IS forcing Windows, Mac, and BeOS users to understand what the UNIX epoch is. 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. One thing C has done well that we can learn from is making libraries system-dependent, but the language system-independent. Leave time() and localtime() (UNIX dependent) in Unix::Time or some other module, easily accessible through a "use Unix::Time". But make the core language easily accessible to everyone. That's where mjdate() comes in, IMO. -Nate
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
Is Perl currently using different epochs on different platforms? If so, I Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical reason IIRC. perlfunc states that time() returns seconds since machine epoch, noting that it varies from platform to platform. (As some have noted, the Mac epoch is in 1904. I think this is so you can divide the years since epoch by 4 and have the remainder indicate the leap-year condition. Wouldn't have worked for 1900, and most of us have probably dealt with that fact at some point, by now.) It might be advisable for portability concerns to standardize on an epoch. If so, this Mac user would vote for the UNIX epoch. It is simply the most widely accepted. I'm not sure what Windows does, but I thought I might have seen something that implied it was using (or at least converting to and from) UNIX epoch. Mac will probably use that epoch, anyway, once OS X comes out (which will fuse Mac OS and UNIX in what I expect will be a beautiful way). I always treat the return value of time() as a black-box value. I can perform specific actions on it, such as feeding it to localtime() or adding relative time intervals to it, such as a year of seconds. But I do not allow myself to look at that value. I was kind of hoping Perl6 would formalize this into a black-box value, meaning an object, and offload everything into a standard module instead of the core. Kirrily and Dan, isn't it time for a time and date sublist? J. David
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
Is Perl currently using different epochs on different platforms? If so, I Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical reason IIRC. can definitely see the wisdom in doing something about *that* and off-loading the system-local time processing into modules (although I can also see the wisdom in leaving well enough alone). But why not go with the most commonly used and most widely analyzed epoch? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, 14 Aug 2000, Nathan Wiger wrote:
1. time() would still return UNIX epoch time. However, it
would not be in core, and would not be the primary
timekeeping method. It would be in Time::Local for
compatibility (along with localtime and gmtime).
2. mjdate() would return MJD. It _would_ be in core, and
it _would_ be the internal timekeeping method. All
of the new date functions would be designed to be based
off of it.
So, just to clarify:
1. The Perl 5 way in Perl 6:
use Time::Local;
$date = localtime time();
2. The Perl 6 native way:
$date = date mjdate();
Now, are we talking about the new default/de facto standard that the
users are being presented with? Or are we talking about the true
internal structure? ("and it _would_ be the internal timekeeping
method.")
I don't have an OS that reports time in MJD. It seems
counter-productive (IMHO) for Perl (internally) to convert from
whatever the native platform time measurement is to MJD, only to
convert it back to the native format again, if that never is presented
to the users.
For example:
# From 5.6 perlfunc
$now = time;
utime $now, $now, @ARGV;
Under this proposal, time would (under Unix), return the number of
epoch seconds, which would then be converted to MJD internally. This
stored MJD would then have to be converted back to the original epoch
seconds, (perhaps twice), for the argument to utime? Alarms and
timers, file tests - any time interface outside of Perl itself - these
*all* will be converted to MJD internally?
(Assuming, of course, that you don't explicitly change the arguments to
utime to accept MJD, although it would still have to be converted to
native format anyway.)
I can understand wanting to present the user with a common,
multi-platform, consistent date/time interface, but I don't understand
extending that to the internals.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On 14 Aug 2000, Russ Allbery wrote: Day resolution is insufficient for most purposes in all the Perl scripts I've worked on. I practically never need sub-second precision; I almost always need precision better than one day. MJD allows fractional days (otherwise it would of course be useless). As I write this the MJD is 51771.20833 I recognize that a lot of software packages out there are using MJD, but I don't really feel that fractions of days, hours, or minutes are intuitive. Mankind has had sixty seconds in a minute, sixty minutes in an hour, twelve hours in a day, and so on up, for centuries. Arguably, better systems could be created, and perhaps MJD is such a system, but it is very hard to change the instincts and habits built on older systems. (Just look at how slowly the U.S. is moving to metric.) I would really rather not see this change, or see the number expressed in seconds. (MJD as seconds would really amount to just moving the epoch, and I don't think that would make anyone happy.) I still lean towards thinking that anything involving a date should be pushed out into a module. There could be a date module (or two) included as standard, and people who want MJD or other systems, or fractions of a second, or whatever, could totally ignore the standard module and use a different one. J. David
RE: Proposed enhancement to the warnings pragma for Module writers
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
On Sun, Aug 13, 2000 at 09:36:48PM -0400, Ronald J Kimball wrote:
On Sun, Aug 13, 2000 at 09:04:41PM +0100, Paul Marquess wrote:
I'm cc-ing this to p6 because there doesn't seem to be anyone left on
p5p.
Then who is generating all this traffic on p5p? :D
I'm certainly still there, as you can tell from everyone correcting my
patches. :)
Sorry guys, forgot the smiley.
warnings::warnif($category, "message") ;
instead of this:
if (warnings::enabled($category))
{ warnings::warn($category, "message") }
Any reason why that isn't the behavior of warnings::warn()?
Because there are occasions when you want to force a mandatory warning.
Correct.
Paul
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
Tim Jenness [EMAIL PROTECTED] writes: On 14 Aug 2000, Russ Allbery wrote: Day resolution is insufficient for most purposes in all the Perl scripts I've worked on. I practically never need sub-second precision; I almost always need precision better than one day. MJD allows fractional days (otherwise it would of course be useless). As I write this the MJD is 51771.20833 Floating point? Or is the proposal to use fixed-point adjusted by some constant multiplier? (Floating point is a bad idea, IMO; it has some nasty arithmetic properties, the main one being that the concept of incrementing by some small amout is somewhat ill-defined.) At some level time() will have to be changed to support fractions of a second and this may break current code that uses time() explicitly rather than passing it straight to localtime() and gmtime(). Agreed. I guess I don't really care what we use for an epoch for our sub-second interface; I just don't see MJD as obviously better or more portable. I'd actually be tentatively in favor taking *all* of the time stuff and removing it from the core, under the modularity principal, but I don't have a firm enough grasp of where the internals use time to be sure that's a wise idea. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
