Re: RFC 80 (v1): Exception objects and classes for builtins
Redirected to perl6-language-flow. At 12:23 PM 8/11/00 +0100, Graham Barr wrote: On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote: If we're really talking about new keywords, we wouldn't need a ; at the end of the last block; it's only needed at the moment because eval is a function, not a keyword. I would vote for the keywords only because people are going to forget the ; otherwise. That maybe a reason to use `try' instead of `eval'. Another difference would be that try will rethrow uncaught error, eval does not. And of course a die in any catch block would throw an error to a try/eval block up the stack, after running the continue block. So adie; in the catch block would rethrow the same error. If we did use 'try', would we retire the block form of 'eval'? It could be confusing to have a keyword with almost identical but subtly different semantics to a function. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes: NI Uri Guttman [EMAIL PROTECTED] writes: i think we do because a thread can block on a mailbox while it can't on an array. NI Why not ? - I see no reason that a "shared" array could not have NI whatever-it-takes to allow blocking. then every op that could touch an array has to have code to support blocking. i think that would be a mess. and what is the definition of blocking on an array, is it empty? can i pop or shift it? how do you handle atomicity? how do you specify a non-blocking access (poll) on an array? mailboxes are defined to work fine with those requirements. a get on a mailbox will block until one item is retrieved and that is an atoamic operation. a get can be made non-blocking (polling) with a optional argument. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Nope. The code that accessses the array needs to support it. Different DS animal entirely. The ops don't actually need to know. but still that is overhead code for all arrays and not just the mailbox ones. DS s/mailboxes/filehandles/; DS If we're talking a generic communication pipe between things, we DS should overload the filehandle. It's a nice construct that DS provides an ordered, serialized, blockable, pollable DS communications channel with well-defined behavior and a DS comfortable set of primitives to operate on it. pollable is a good thing. some mailbox designs are not pollable and some are. i like the idea of supporting polling then you can also have callbacks. but this does imply an implementation as semaphores and shared memory are not pollable. you would have to build this with pipes and filehandles. overlaying it on filehandles is another question. i would like to see a single operation which does an atomic lock, block, retrieve, unlock. we don't have that for filehandles. you could use a new method on that special handle (i like 'get') which has the desired semantics. i think making mailboxes in some form is a good idea. but they should be special objects (even if they are filehandles) with their own methods to support the desired semantics. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals
At 12:54 PM 8/11/00 -0400, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Nope. The code that accessses the array needs to support it. Different DS animal entirely. The ops don't actually need to know. but still that is overhead code for all arrays and not just the mailbox ones. Nope. Just for the shared ones. DS s/mailboxes/filehandles/; DS If we're talking a generic communication pipe between things, we DS should overload the filehandle. It's a nice construct that DS provides an ordered, serialized, blockable, pollable DS communications channel with well-defined behavior and a DS comfortable set of primitives to operate on it. pollable is a good thing. some mailbox designs are not pollable and some are. i like the idea of supporting polling then you can also have callbacks. but this does imply an implementation as semaphores and shared memory are not pollable. you would have to build this with pipes and filehandles. So? Inter-thread communication is almost undoubtedly not going to be built with something as heavyweight as pipes, shm, or mailboxes, so I don't see their limitations as relevant here. Regardless, don't design to the limitations of one particular implementation method. We can work around their limits if need be. overlaying it on filehandles is another question. i would like to see a single operation which does an atomic lock, block, retrieve, unlock. we don't have that for filehandles. you could use a new method on that special handle (i like 'get') which has the desired semantics. So we enhance filehandles to make reads on them atomic. does an atomic read on the filehandle. NBD. i think making mailboxes in some form is a good idea. but they should be special objects (even if they are filehandles) with their own methods to support the desired semantics. Overload filehandles. They really are a good fit for what you're looking for. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 80 (v1): Exception objects and classes for builtins
I've moved this from perl6-language to perl6-language-flow.
Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO { ... }
case Socket { ... }
}
}
Graham Barr wrote:
the error are objects, so you need to allow for inheritance.
I was just trying to point out that RFC 88 uses try {} catch {}
instead of try {} otherwise {}, and that the current error comes
into the catch block via @_ (as in RFC 63), so one doesn't need a
"global".
Sometimes you want to collect all the catching into one clause (if,
say, there was lots of common code and little varying code). In
other cases, you want a seperate clause for each exception (if, say,
there is little common code, then the seperate clauses handle the
switch for you, which is more DWIM). That's why RFC 88 allows you
any combination of these operations, as in:
try {
}
except isa = "Foo" = catch { ... }
except isa = "Bar" = catch { ... }
except else = catch { ... }
Again, the differences between this and RFC 63's approach are, in
this case, only syntactic.
Yours, c, Tony Olekshy
Re: RFC 80 (v1): Exception objects and classes for builtins
I've moved this from perl6-language to perl6-language-flow.
Graham Barr wrote:
eval {
# fragile code
}
else { # catch ALL exceptions
switch ($@) {
case __-isa('IO') { ... }
case __-isa('Socket') { ... }
else { ... }
}
}
continue {
# code always executed (ie finally)
}
Chaim Frenkel wrote:
Nice.
Hmm. The eval was commented to indicate fragile code, which is
implied if the keyword try is used. The else was commented to
indicate a catch, instead of saying catch, and the continue was
commented to indicate a finally, instead of saying finally.
There does seem to me to be some benefit to the clarity of the
RFC 88 approach, which supports both:
try { }
except isa = 'IO' = catch { }
except isa = 'Socket' = catch { }
except else= catch { }
finally { }
and:
try { }
catch {
switch ($_[0]) {
case __-isa('IO') { ... }
case __-isa('Socket') { ... }
else { ... }
}
}
finally { }
Yours, c, Tony Olekshy
Re: RFC 80 (v1): Exception objects and classes for builtins
On Fri, Aug 11, 2000 at 09:36:32AM -0700, Peter Scott wrote:
Redirected to perl6-language-flow.
At 10:39 AM 8/11/00 -0400, John Porter wrote:
Piers Cawley wrote:
The (continue|always|finally|whatever) clause will *always* be
executed, even if one of the catch clauses does a die, so you can use
this to roll back the database transaction or whatever else was going
on and restore any invariants.
Which makes me think that it would be nice if the continue block could
come before the catch block(s):
establish_invariants();
try {
something_risky();
}
continue {
restore_invariants();
}
catch {
handle_error_assuming_invariants_restored();
}
The only point of using the continue block as you suggest is if there are
multiple catch blocks, otherwise you'd just do
Hm, my understanding is that the continue block would be run it there was
an error or not.
So with no errors you do
execute try
execute continue
but if there was an error
execute try
- die
execute continue
execute catch
Graham.
Re: RFC 80 (v1): Exception objects and classes for builtins
Peter Scott wrote:
John Porter wrote:
Which makes me think that it would be nice if the continue block
could come before the catch block(s).
I get where you're going with this but it breaks the paradigm too
much. Now you need a 'finally' block again.
Sometimes you want before, sometimes after, as in:
try {
open(*F, "foo") or throw "Can't open foo.";
print F ...;
}
finally { close F or throw "Can't close foo."; }
unwind { attempt_to_log_error_message($_[0]); }
which can also be written as:
try {
try {
open(*F, "foo") or throw "Can't open foo.";
print F ...;
}
finally { close F or throw "Can't close foo."; }
}
catch { attempt_to_log_error_message($_[0]); throw; }
The exception handling mechanism considered in RFC 88 has both
pre-finally and post-finally exception trapping clauses, named
catch and unwind.
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.
Yours, c, Tony Olekshy
Re: RFC 14 (v3) Modify open() to support FileObjects and
# Open a remote webpage
$http = open http "http://www.perl.com/", GET;
^
1) The URL says that it's a http resource, so why do we have
to tell open to use a http handler?
a) Allows custom handlers:
open myhttp "http://www.perl.com/";
b) Handles stuff without requiring URI syntax:
open dir "C:\Windows\System"; # the "C:" handler?
2) We are opening it for input ("If MODE is '' or nothing,
the file is opened for input." -- perlfunc), so why do we
have to tell open to use the GET method?
Fine with me - here's a stab at http MODES:
= GET# optional
= PUT
+ = POST
= HEAD # ??
-Nate
RFC 14 (v3) Modify open() to support FileObjects and
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Modify open() to support FileObjects and Extensibility
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 04 Aug 2000
Last-Modified: 11 Aug 2000
Version: 3
Mailing List: [EMAIL PROTECTED]
Number: 14
=head1 ABSTRACT
Currently, Copen(), Copendir(), Csysopen(), and other file open
functions are given handle arguments, whose values are twiddled if a
filehandle can be created:
open(HANDLE, "$filename");
open PIPE, "| $program";
open my $fh, "$filename";
opendir DIR, $dirname;
sysopen(HANDLE, $filename, O_RDWR|O_CREAT, 0666);
There are several problems with this approach:
1. The calling style is uncharacteristic of other Perl funcs
2. There is no way to support a list of return values
3. There is no way to overload or extend them
In order to make these functions more consistent with other constructor
like functions (i.e. new(), etc), they should be changed to instead
return Bfirst-class fileobjects:
$fo = open "$filename" or die;
$po = open "|$program" or die;
$do = open dir $dirname or die;
$so = open sys $filename, O_RDWR|O_CREAT, 0666;
This would make these functions more internally consistent within Perl,
as well as allowing for the power of true Bfileobjects and an
extensibile Copen().
=head1 DESCRIPTION
=head2 Overview
First, this RFC assumes that Bfileobjects will be $ single-whatzitz
(thanks Tom) types, which seems to have reached an overall informal
consensus.
As many have observed, the current filehandle mechanism is insufficient
and largely "a historial accident". The goal of the redesign of file
handles into full-fledged Bfileobjects is to make them as flexible and
powerful as other objects within Perl, which still retaining a means to
interact with them simply. Since we are redesigning filehandles to be
true Bfileobjects, we should revise their constructor functions as
well, returning Bfileobjects and providing extensibility.
As shown above, in the simplest case this would change the Copen()
function to:
$fo = open $filename or die;
If successful, Copen() and its relatives will return Bfileobjects.
On failure, they will return undef. This still allows the user to test
the return value of Copen() (as shown above) by checking for a "true"
(Cfileobject) or "false" (undef) condition.
=head2 New Syntax of Copen()
The syntax of the Copen() function would be changed as follows:
$fileobject, [ @params ] = open [ $handler ] $file, [ @args ];
Let's examine this syntax more closely:
$fileobject - Replacement object for current filehandles.
@params - Optional parameters that may be returned in a list
context. These may be things such as the owner for
a true file, or the content-type for a web document.
$handler - The class from which to load the appropriate file
methods, the default being "file". This is not
really a class, but rather a registered handler. This
handler type is bound to a class given by the user,
or taken from a set of core methods. Think Apache
handler.
$file- File to open. This might be a real file or directory,
but might also be a website, port for a socket,
ftp server, ipc pipe, rpc client, and so on.
@args- Optional arguments to pass to the handler's Copen.
The Copen function, as I propose it, is an overloaded and extensible
function that differs from other constructors in that it returns a valid
Bfileobject. This object can then be used in Cread, Cprint, and
other such file functions. As such, development of classes that can
handle objects on new platforms (ex: Mac, Palm) and handle new types of
files (XML documents, etc) is much quicker. Plus, these modules are much
lighter weight since they don't have to reinvent the wheel every time.
=head2 Simple Scalar Form
In the simplest, "looks like Perl 5" form, Copen() can take one file
parameter, which is then opened per the descriptor provided and the
corresponding Bfileobject returned. Here are some examples (note that
Cmy has been left out for clarity):
# Read from a file
$fo = open "/etc/passwd" or die;
print while ($fo);
close $fo;
# Write a file to a pipe
$mailpipe = open "|/usr/lib/sendmail" or die;
($motd, $owner) = open "/etc/motd"; # return owner in list
die unless $owner == 0;# owner not root
while ($motd) {
print $mailpipe;
}
close $motd;
# Go fork yourself
($myself, $pid) = open "-|" or exec 'ls'; # return PID in list
print while ($myself);
close $myself; # not myself anymore, hah! ;-)
In addition, the C$file argument becomes optional in this new syntax.
If not supplied, it defaults to C$_, making it consistent with other
Perl
Internal Filename Representations (was Re: Summary of I/O related RFCs)
[cc'ed on internals as FYI] =item 36 (v1): Structured Internal Representation of Filenames I think this should be discussed a good amount. I think URIs are cool, but too much trouble for simple stuff. I don't want to have to write "file:///etc/motd" everytime I want to address a file. Too cumbersome. Plus, on Windows it turns into junk like "file://C|/Windows". Icky. Here's an idea. Our new nifty fileobjects ($fo) could have some "jars" where path info is stuck internally automatically. We could have methods for: $fo-pathdrive # Windows drive $fo-patharray # array of split-up filename $fo-pathdelim # / or \ or :: or ? So trace this call: $fo = open "C:\Windows\System\IOSUBSYS\RMM.PDR"; $fo-pathdrive = "C:" ; $fo-patharray = [ Windows, System, IOSUBSYS, RMM.PDR ]; $fo-pathdelim = "\"; So, this would be the internal representation of the filename. A UNIX one would be similar, it's just that the drive jar would be empty: $fo = open "/etc/inet/inetd.conf"; $fo-pathdrive = ""; $fo-patharray = [ etc, inet, inetd.conf ]; $fo-pathdelim = "/"; Splitting apart or putting together either one of these paths is trivial - it requires the exact same operations as long as you know the delimiter (the OS should tell you that): ($fo-pathdrive, $fo-patharray) = split $fo-pathdelim, $filename; $filename = join $fo-pathdelim, $fo-pathdrive, $fo-patharray; Hey, I kinda like that...(of course, I'm biased)... :-) -Nate P.S. I know the split code won't work exactly like that (assigning to funcs as lvalues), but I thought it was the clearest way to write it.
Re: RFC 83 (v1) Make constants look like variables
How would this take into account stuff like this:
sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644);
The "O_RDWR|O_CREAT" part is what I'm talking about here. This is a
constant w/o suffix. We'll either have to:
1. Change it to $O_RDWR|$O_CREAT or $O{RDWR}|$O{CREAT}
Maybe for errors us $E{AGAIN} and so on?
2. Make special exceptions for "special" constants
I'd *definitely* prefer #1, although we do run the risk of confusing
some C folks. Not that that should stop us, but just something to think
about. The %O and %E hashes might be kind of neat - you could check out
all the supported options and errors just by walking a hash with a short
C-esque name. Plus the top-level namespace is much cleaner.
-Nate
Re: RFC 85 (v1) All perl generated errors should have a
Perl6 RFC Librarian [EMAIL PROTECTED] writes, for Chaim Frenkel
[EMAIL PROTECTED]:
[...]
=item As a floating point number
The integer part would be the actual identifier. The fractional
part could encode some classification scheme.
Floating point numbers don't work this way. Suppose I use a machine
with non-IEEE floats. Then some floating point numbers which are
exactly specifiable in IEEE fp might not be so on my machine, so I'll
get really weird error numbers. Does the comp.lang.perl.* hierarchy
really need, in addition to "BUG IN PERL: I added 0.1 to itself 10
times and didn't get 1.0" messages, some _justified_ posts about
difficulties with floating-point precision? Or does this mean I can't
build Perl on a machine without IEEE fp?
Note that this would also mean that many plausible schemes for dealing
with error codes (e.g. "I know it's an error of class 123 subclass 4,
so I'll just subtract 123.4 and multiply by 1e4 to get the remainder)
will require careful analysis of precision. Sounds like another one
of my CS sophistries? Try this:
selena 107 [9:15] ~ perl -de 42
Loading DB routines from perl5db.pl version 1.0402
Emacs support available.
Enter h or `h h' for help.
main::(-e:1): 42
DB1 $err = 123.4567
DB2 x $err-123
0.4566998
And we all know the next line of code will be
if (($err-123) =~ /^0.4567/) {
# DANGER! Reactor meltdown unless shut down
}
else {# Whew! That was close...
warn "non-fatal error encountered: $err\n";
}
Since you're anyway not using a _floating_ point, here are 2
alternatives:
1. Error codes are integers, but with an implied decimal point (fixed
point). E.g. 1234567 represents error 4567 in class 123.
2. Error codes as digit strings with decimal point. So "123.4567"
(_not_ 123.4567) represents error 4567. People will still try
stupid floating-point math tricks to get at the suberror code, but
at least we'll know they didn't read the bit in the documentation
where it will specifically warn _not_ to do this.
[...]
--
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 85 (v1) All perl generated errors should have a
"AS" == Ariel Scolnicov [EMAIL PROTECTED] writes: AS 2. Error codes as digit strings with decimal point. So "123.4567" AS(_not_ 123.4567) represents error 4567. People will still try ASstupid floating-point math tricks to get at the suberror code, but ASat least we'll know they didn't read the bit in the documentation ASwhere it will specifically warn _not_ to do this. well, if it is only a string, why use . as the separator? use something else like : and no one will try any fancy math tricks on it. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t
Graham Barr [EMAIL PROTECTED] writes:
Damian Conway [EMAIL PROTECTED] writes:
Leon Brocard writes:
=head2 $AUTOLOAD
While we're at it, it *may* be a good idea to remove the
global $AUTOLOAD variable and instead pass it as the first
parameter of the AUTOLOAD subroutine call. For: general
global drought, the fact that perlsub's argument "because,
er, well, just because, that's why..." is a bit weak.
Against: makes AUTOLOAD more complicated, breaking the
"subroutine parameters end up as @_" paradigm (apparently).
This, I really like.
But it will slow things down. Firstly because it must be added to
the stack then removed inside the sub.
I don't see any issue keeping $AUTOLOAD as the way the sub name is
passed.
If we're going with named parameters for subroutines elsewhere can't
we do a bit of magic here? $AUTOLOAD becomes lexically scoped for the
AUTOLOAD subroutine a la named parameters, but is not present in @_.
Hmm... maybe we could have the AUTOLOAD sub refuse to handle a method
by raising an Exception::AUTOLOAD::DECLINE, by analogy with mod_perl
it could also raise an Exception::AUTOLOAD::REFUSED which would
terminate the dispatch process.
Note that this has the advantage of letting old style AUTOLOADs 'just
work' if we just pass any other exceptions up the stack and pass the
return value back as per always.
--
Piers
'063039183598121887134041122600:1917131105:Jaercunrlkso tPh.'=~/^(.{6})*
(.{6})[^:]*:(..)*(..).*:(??{'.{'.$2%$4.'}'})(.)(??{print$5})/x;print"\n"
Re: RFC 84 (v1) Replace = (stringifying comma) with =
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 84
I like this a lot, especially the way it deals with subroutine
parameters.
But... would it be possible to exten this proposal so that, if the right
hand operand is an array or hash variable, it will create a reference to
this variable?
That would allow subroutine calls like:
foo('names' = @names, 'size' = 'A4', 'labels' = %labels)
to do the Right Thing. It would even make the CGI.pm interface easier
for newbies...
Hildo
Against overloading || and (RFC 20) -- we just need lazy evaluation
I think the whole idea of overloading the '' and '||' operators is too farfetched. It's and incredibly dangerous can of worms, precedence rules changing, shortcircits not working, etc. Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, where you have a possibility to create ordinary looking functions (in Lisp, there's no difference between a function and an operator; the less polite name is "prefix notation"); but the calculation of the values of the parameters can be postponed until the time when the sub is already running. In fact, it won't be calculated, unless you invoke it yourself. (How? "eval"?) Then, we could simply write our own versions of shortcutting AND and OR. The difference would be that it would look like a function, not like an operator. Compare: expr1 expr2 vs. AND(expr1, expr2) but at least, there would be no confusion WRT precedence rules. -- Bart.
Re: RFC 76 (v1) Builtin: reduce
On 11 Aug 2000 09:30:03 +0300, Ariel Scolnicov wrote (and quoted):
reduce avg $identity, @list
This was my first point regarding Creduce -- not all functions have
an identity element. One should note that in general
(reduce avg $x,@list) != (reduce sum 0,@list)/@list
for Iany value of $x; your reduction is Inot the right way to
compute an average (I don't know if it was meant to be or not, but it
got me).
If you can tell me why you wish to perform this reduction, you should
also be able to figure out an identity element. You're computing
(($list[0]+$list[1])/2 + $list[2])/2 + ...
for some reason.
I have some reservations about this reduce() thing. Plain and simple
incorporating it into the core language would introduce the chance for
lots of buggy programs, like the example Arial gave. In fact, I think
that *most* programs that use reduce() would be buggy. But there is more
still.
On a more theoretical plane, what does
reduce { $_[0] OP $_[1] } $x, $y, $z;
represent? Is it the programmer's idea of this?
$x OP $y OP $z
But, is that:
($x OP $y) OP $z
or
$x OP ($y OP $z)
We are used to thinking of associative operators, like "+" and "*",
where it makes no difference. A simple replacement by "-" is already a
counter example. The "average" example above, is too. (An "operator" and
a "function" are basically the same thing with a different notation.) I
think that *virtually all* programs that people would write using
reduce(), would fall into this category.
Besides, in functions like map() and grep(), execution order shouldn't
matter. I think that *still* the processing order of the arguments isn't
officially stated as "always from left to right" (as with the coma
operator), even though highly respected Perl hackers like Abigail (see
comp.lang.perl.misc) strongly depend on it. So, what's it going to be
here? I think that if your code depends on execution order, you
shouldn't be using this functional programming paradigm.
I think we don't really need reduce(). There are well working,
relatively simple, and *far more transparent* alternatives, at least,
for Perl. We do have OP= operators, after all. For example:
$total = 0;
map { $total += $_ } @list; # if you insist...
return $total;
How is this so bad, compared to:
reduce { $_[0] + $_[1] } @list
Is the latter shorter? Hardly. Would it be faster? I doubt it. Is it
more transparent to see what it does, or is supposed to do? NOT AT ALL.
--
Bart.
Re: RFC 80 (v1): Exception objects and classes for builtins
On Thu, Aug 10, 2000 at 06:43:30PM -0400, Chaim Frenkel wrote:
"GB" == Graham Barr [EMAIL PROTECTED] writes:
GB On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote:
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the 'else' clause indicate that the exception
was handled?
GB By not rethrowing it. ie if it does not want to handle the
GB error itself it just callsdie;
GB Which will call PROPAGATE on the object in $@, just like perl5, then
GB look back up the call-stack for the next eval { }
Hmm, we must be coming from different backgrounds.
I expect my exception handler to rethrow if not handled. I expect
the continue block to be run under both conditions, and be responsible
for ensuring consistancy.
Let's look at it from how the validity of the data (or object)
# -- Invariant True
eval {
# -- Invariant True
# -- Invariant True
}
else {
# -- Invariant might be invalid
...
# --
}
continue {
# --
...
# -- Invariant True
}
# -- Invariant True
What would you want at the exit point of the else or the entry point
of the continue? Is the job of the continue to restore the invariant
or is it the job of the else clause.
The else it catching the errors. Remeber that with perls eval it is upto
you to deal with $@, perl does not magically die again if you do nothing
as you can ignore it if you want to.
So following on from that the else block deals with the error if it
wants to. One of it's options is to pass it on up the call stack.
The otherwise will always be called on exit of the else block, whether
it be exiting by a natural path or by calling die.
Graham.
Re: RFC 80 (v1): Exception objects and classes for builtins
On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote:
So I'm thinking:
eval { ...
} catch Exception::Foo {
...
} catch Exception::Bar, Exception::Baz {
...
} catch {
... # everything else, but if this block is absent, uncaught exceptions
# head up the call stack
} continue {
... # Executed after everything
}
I maybe warming to this idea.
If we're really talking about new keywords, we wouldn't need a ; at the end
of the last block; it's only needed at the moment because eval is a
function, not a keyword. I would vote for the keywords only because people
are going to forget the ; otherwise.
That maybe a reason to use `try' instead of `eval'. Another difference would
be that try will rethrow uncaught error, eval does not. And of course
a die in any catch block would throw an error to a try/eval block up the
stack, after running the continue block. So adie; in the catch
block would rethrow the same error.
I like reusing 'continue' since I use 'finally' blocks about as often as I
use 'continue' blocks anyway :-)
Right.
Graham.
Re: RFC 80 (v1): Exception objects and classes for builtins
On Thu, Aug 10, 2000 at 07:47:47PM -0600, Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO { ... }
case Socket { ... }
}
}
Nope, the error are objects, so you need to allow for inheritance.
Graham.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote: I find nothing in the documentation that suggests that = is anything other than a plain comma operator, yet you call it a "first-argument-stringifying comma operator". In fact, the documentation explicitly claims "=" is a synonym of "," (see perldata). I wonder what old version of the docs you are using. My perldata says: The `=' operator is mostly just a more visually distinctive synonym for a comma, but it also arranges for its left-hand operand to be interpreted as a string--if it's a bareword that would be a legal identifier. Calling "=" a synonym for "," is not the whole truth. It ignores the presence of the word "mostly" in that sentence, for one. -- Bart.
Re: RFC 76 (v1) Builtin: reduce
On Thu, Aug 10, 2000 at 07:22:21PM -0400, Chaim Frenkel wrote: Okay, then for reduce avg $identity, @list What should $identity be? I would like to see what avg would be, given that each time it would be passed the previous result (or the first element) and the next element. So without using an external variable to keep count of how many elements had been processed so far it could not be done. So you would probably do it like (reduce __+__ 0, @list) / @list. This will ensure that the sum is defined. However this is probably just a bad exanple of why not to require an identity element. A better example might be trying to perform join, with reduce eg reduce __.','.__ $identity, @list Which would not work for any value of $identity unless you did reduce __.','.__ shift @list, @list which is probably a good example why not to require an identity element. Graham. "AS" == Ariel Scolnicov [EMAIL PROTECTED] writes: AS Think of the first element of the list as different from the rest -- AS it is the initial value to reduce from (for + and *, you'll usually AS pick an appropriate identity element). By writing AS @sum = reduce __+__ 0, @numbers AS you deal elegantly with both cases. AS NOTE: I find this trick very elegant. I wish it were my trick, AS instead of Damian's... -- Chaim Frenkel Nonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Thu, Aug 10, 2000 at 10:21:37PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head2 Pairs and arrays
When a pair reference is assigned (in)to an array, it remains a single scalar
(referential) value. So:
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
But won't this cause breakage to existing scripts
=head2 Pairs and subroutines
When a pair reference is used in the argument list of a subroutine with
no parameter list, it is passed as a single scalar value (i.e it remains
a pair reference).
When a pair reference is passed to a subroutine with named parameters, it
binds its value to the parameter of the same name, regardless of the order
in which it is passed.
Thus:
use Data::Dumper;
sub no_params {
print "no_params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
sub params ( $name, $rank, $serial_num) {
print "params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
no_params(serial_num=1234, name='demo', rank='RFC');
params(serial_num=1234, name='demo', rank='RFC');
prints:
no_params:
PAIR
PAIR
PAIR
$VAR1 = ( 'serial_num' = 1234 );
$VAR2 = ( 'name' = 'demo' );
$VAR3 = ( 'rank' = 'RFC' );
params:
scalar val
scalar val
scalar val
$VAR1 = 'demo';
$VAR2 = 'RFC';
$VAR1 = 1234;
Note that these semantics still support the popular:
sub hash_like_args {
my %args = @_;
# etc.
}
But they will break the idiom of
sub list_of_op_value_parameters {
while(my($op,$value) = splice(@_,0,2)) {
# process
}
}
list_of_op_value_paramaters(add = $v1, replace = $v2, add = $v3);
Graham.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Fri, Aug 11, 2000 at 11:24:48AM +1000, Damian Conway wrote:
This can be correctly handled. The named parameter's context specifier
would be propagated to the right operand of the =. So:
sub demo ( $name, \%options ) {...}
will accept:
demo(options=%myopts, name='my name');
but in the case of
sub demo ($name, %options) {...}
what does
demo($var, name = $value);
do ?
Graham.
Re: the currying operator
Graham Barr [EMAIL PROTECTED] writes:
On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote:
Mike-
Jeremy's got a great explanation of this, which I'll paraphrase, but the
discussion went through lots of iterations. Think of the ^ as a carat or
thumbtack, holding the place for later variables. Then, consider the
parallels:
Placeholder Variable
Anonymous ^_ $_
Numbered^1 ^2 $1 $2
Named ^bob ^jim $bob $jim
When you look at the symmetry this way, I think it makes a ton of sense
and even makes currying a lot more understandable. In fact, I think the
syntax is very Perlish.
I agree, however I wonder if ^ is the right character. Consider a
currie function that used a regexp
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just like you do with
variables.
So I would suggest something like one of : _
Not sure about :, but how you do distinguish between _foo =
placeholder and _foo = _foo?
--
Piers
'063039183598121887134041122600:1917131105:Jaercunrlkso tPh.'=~/^(.{6})*
(.{6})[^:]*:(..)*(..).*:(??{'.{'.$2%$4.'}'})(.)(??{print$5})/x;print"\n"
Re: RFC 84 (v1) Replace = (stringifying comma) with =
"Glenn" == Glenn Linderman [EMAIL PROTECTED] writes:
Glenn No, but the documentation for strict is some of what I reread
Glenn before making a fool of myself arguing with Damian, and it says
Glenn nothing about barewords, as far as I could read.
Even this part? ...
strict subs
This disables the poetry optimization, generating a
compile-time error if you try to use a bareword
identifier that's not a subroutine, unless it
appears in curly braces or on the left hand side of
the "=" symbol.
use strict 'subs';
$SIG{PIPE} = Plumber; # blows up
$SIG{PIPE} = "Plumber"; # just fine: bareword in curlies always ok
$SIG{PIPE} = \Plumber; # preferred form
Looks pretty direct to me. Maybe that was further than you could
read? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 02:29 PM 8/11/00 +1000, Jeremy Howard wrote: Dan Sugalski wrote: The syntax is actually: my type $varname; This is in perl 5.6.0. Modifiers go as attributes after the colon: my Dog $spot : constant = new Dog; Yes. But what about types and attributes within complex types? What about them? Attributes can take parameters easily enough: my bigint $pi : constant : digits(7) = "3.1415926" Also, do we want to be able to specify types and attributes within a sub prototype? It would be nice to guarantee that subs don't mutate particular parameters, that certain data will not be aliased, etc, so that appropriate optimisations can be done. I'm not sure I'd sweat the optimization stuff at this point. Besides, it's unlikely that the optimizer will know anything about attributes of non-core variable types anyway, so... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: the currying operator
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just like you do with
variables.
No that won't work either. That matches the string {_}
It is the fact that ^ is the first char of the re that causes to to be interpreted
as a re special char.
So I would suggest something like one of : _
Not sure about :, but how you do distinguish between _foo =
placeholder and _foo = _foo?
Ah yes _ is out
Graham.
Re: the currying operator
Graham Barr [EMAIL PROTECTED] writes:
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just like you do with
variables.
No that won't work either. That matches the string {_}
No, \{_\} matches the string {_}. Damn, it doesn't. How annoying.
Well, it *should* be that way, and it shouldn't be too hard to make it
that way. He said hopefully...
It is the fact that ^ is the first char of the re that causes to to be interpreted
as a re special char.
So I would suggest something like one of : _
Not sure about :, but how you do distinguish between _foo =
placeholder and _foo = _foo?
Ah yes _ is out
And : is being mooted for all sorts of other stuff elsewhere. My
current thinking is that ^_ is the best of a not desperately good load
of options.
--
Piers
Re: the currying operator
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham No that won't work either. That matches the string {_}
But that's arguably a DWIMmy thing, since {} is in the category of * +
and ?, which always need to be *after* something, and there's no
*something* here. I don't know how much stuff this would break, but I
know I always backwhack my {'s regardless of where they are located in
the regex, not counting on the DWIM to do it right.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: the currying operator
On Fri, Aug 11, 2000 at 02:03:47PM +0100, Graham Barr wrote:
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just like you do with
variables.
No that won't work either. That matches the string {_}
It is the fact that ^ is the first char of the re that causes to to be interpreted
as a re special char.
Just to confuse things further, if RFC 72 (backwards regexps) is
accepted, then ^ may have this special meaning of "beginning of target
string" even in the middle of the regexp.
Peter
Re: the currying operator
On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote: Mike- Jeremy's got a great explanation of this, which I'll paraphrase, but the discussion went through lots of iterations. Think of the ^ as a carat or I only make this annoying and pedantic point because everyone I have seen discussing this has made the same mistake so far: ^ is not a gemological carat, nor a vegetable carrot, but a "caret". This is a Latin verb that means "it is lacking or missing", which, if you think about it is yet another reason it makes a good symbol for a placeholder. Peter
Re: RFC 85 (v1) All perl generated errors should have a
I'm leaning to splitting identifier from the classification. A pure monotonically increasing integer would ensure the non-reuse. And the classification scheme could evolve seperately. Using numbers for the classification scheme would require a translation table. So why not just use alphanumerics. At a minimum I can see, the originator, the severity, and some class. I'm leaning to having the class tie in with lexical warnings. chaim "AS" == Ariel Scolnicov [EMAIL PROTECTED] writes: =item As a floating point number AS Since you're anyway not using a _floating_ point, here are 2 AS alternatives: AS 1. Error codes are integers, but with an implied decimal point (fixed ASpoint). E.g. 1234567 represents error 4567 in class 123. AS 2. Error codes as digit strings with decimal point. So "123.4567" AS(_not_ 123.4567) represents error 4567. People will still try ASstupid floating-point math tricks to get at the suberror code, but ASat least we'll know they didn't read the bit in the documentation ASwhere it will specifically warn _not_ to do this. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: the currying operator
Piers Cawley wrote:
Graham Barr [EMAIL PROTECTED] writes:
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just like you do with
variables.
No that won't work either. That matches the string {_}
Damian and I put this example into the RFC explicitly. I like what I wrote
the first time, so I'll just repeat it:
=head2 Resolving ambiguity
The following is ambiguous:
$check_start = $somestring =~ /^_foobar/;
This should be interpreted as an immediate pattern match for '_foobar' at
the start of a string. To cause this to be interpreted as a higher order
function, the ambiguity must be resolved through using braces:
$check_start = $somestring =~ /^{_}foobar/;
which creates a higher order function testing for its argument, followed
by 'foobar', anywhere in $somestring. That is:
$check_start = sub { $somestring =~ /$_[0]foobar/ };
It wouldn't be too hard to get P52P6 to recognise ^{something} in a regex
and quote it, would it? (And to make the quoting work properly...) I was
hoping that the use of {} would seem reasonably intuitive given the
similarity to their use in resolving ambiguity in dereferencing and
interpoling variables.
Re: RFC 80 (v1): Exception objects and classes for builtins
Graham Barr wrote:
If we're really talking about new keywords, we wouldn't need a ; at the end
of the last block; it's only needed at the moment because eval is a
function, not a keyword. I would vote for the keywords only because people
are going to forget the ; otherwise.
That maybe a reason to use `try' instead of `eval'. Another difference would
be that try will rethrow uncaught error, eval does not. And of course
a die in any catch block would throw an error to a try/eval block up the
stack, after running the continue block. So adie; in the catch
block would rethrow the same error.
I support the idea of renaming the block eval as die, and leaving eval
for string eval.
But I'm against the idea of implicit rethrowing in any case.
Sure, other languages do it, but perl doesn't, and personally I think
it's a better paradigm.
If you really want to rethrow unhandled exceptions, you can always
catch { die }
--
John Porter
Re: RFC 80 (v1): Exception objects and classes for builtins
John Porter [EMAIL PROTECTED] writes:
Piers Cawley wrote:
The (continue|always|finally|whatever) clause will *always* be
executed, even if one of the catch clauses does a die, so you can use
this to roll back the database transaction or whatever else was going
on and restore any invariants.
Which makes me think that it would be nice if the continue block could
come before the catch block(s):
establish_invariants();
try {
something_risky();
}
continue {
restore_invariants();
}
catch {
handle_error_assuming_invariants_restored();
}
Hmm... that doesn't really fit with me too well, kind of the wrong
meaning for continue somehow. Somebody suggested unwind:
try {
something_risky()
}
unwind {
restore_invariants()
}
catch {
$@-handle()
}
continue {
do_continuation;
}
Hmm... it gets convoluted doesn't it?
--
Piers
Re: RFC 76 (v1) Builtin: reduce
Damian Conway wrote: More and more I lean towards a scalar-only reduce. Yep! Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need multidimensionals. Combined with highlander variables, and there ceases to be a problem. -- John Porter
Re: RFC 76 (v1) Builtin: reduce
John Porter [EMAIL PROTECTED] writes: Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need multidimensionals. Combined with highlander variables, and there ceases to be a problem. Will you stop with the highlander variables? -- Piers
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
Someone on this list (TomC?) has supplied a major diatribe against const. chaim "JH" == Jeremy Howard [EMAIL PROTECTED] writes: JH Dan Sugalski wrote: The syntax is actually: my type $varname; This is in perl 5.6.0. Modifiers go as attributes after the colon: my Dog $spot : constant = new Dog; JH Yes. But what about types and attributes within complex types? JH - Constant refs vs refs to constants? JH - Types of hash (or 'pair') keys and elements? JH - Attributes (e.g. constantness) of hash keys and elements? JH - Ditto for arrays/lists... JH I left this out of v1 of the RFC because I wanted to get some feedback on JH syntax. If we can flesh this out I'll incorporate it into v2. JH Also, do we want to be able to specify types and attributes within a sub JH prototype? It would be nice to guarantee that subs don't mutate particular JH parameters, that certain data will not be aliased, etc, so that appropriate JH optimisations can be done. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 76 (v1) Builtin: reduce
Bart Lateur wrote:
I have some reservations about this reduce() thing. Plain and simple
incorporating it into the core language would introduce the chance for
lots of buggy programs, like the example Arial gave. In fact, I think
that *most* programs that use reduce() would be buggy.
Whenever people try to use language features with which they are but
passingly familiar (or grossly unfamiliar), buggy programs result.
Again, your argument could also be applied to OO -- but perl isn't
dropping OO any time soon.
We are used to thinking of associative operators, like "+" and "*",
where [operator order] makes no difference.
Besides, in functions like map() and grep(), execution order shouldn't
matter. I think that *still* the processing order of the arguments isn't
officially stated as "always from left to right" ...
So, what's it going to be here?
The answer to this objection is simply to declare an official order
of execution. Left-to-right.
I think that if your code depends on execution order, you
shouldn't be using this functional programming paradigm.
Wrong. Functional programming is in some sense merely procedural
programming but without side-effects. There's no golden rule of FP
saying execution order is irrelevant; and I don't see how there could
be. Maybe you're getting it confused with declarative programming...
I think we don't really need reduce().
Some people thought perl would have been better off without OO, too.
Should Larry of listened to them? Or should he have listened to the
significantly larger number of people (including himself) who though
OO would be a good addition to perl?
There are well working,
relatively simple, and *far more transparent* alternatives, at least,
for Perl.
So, you're saying recursion should be eliminated from perl.
I don't think that's gonna fly.
$total = 0;
map { $total += $_ } @list; # if you insist...
return $total;
How is this so bad, compared to:
reduce { $_[0] + $_[1] } @list
Is the latter shorter? Hardly.
Huh? It's significantly shorter. It's one statement vs. three, and
requires no temporary variables.
Would it be faster? I doubt it.
What do you base that on? The fact that the reduce() version would
involve so many more costly perl OPs?
--
John Porter
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Fri, 11 Aug 2000 11:01:30 -0400 (EDT), Simply Hao wrote: What about with -w: read = $value What warning? Oh, you're probably using a pre-5.005 Perl. 5.004 (the latest MacPerl, for example) still had that warning. 5.005 and later, do not, any more. -- Bart.
Re: RFC 80 (v1): Exception objects and classes for builtins
"PC" == Piers Cawley [EMAIL PROTECTED] writes: PC The (continue|always|finally|whatever) clause will *always* be PC executed, even if one of the catch clauses does a die, so you can use PC this to roll back the database transaction or whatever else was going PC on and restore any invariants. Err, how does one differentiate between a 'good' entry and a 'bad' entry. PC Note too that we don't need to do any case based magic, we can and PC should use polymorphism for that. Why? Just because? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Against overloading || and (RFC 20) -- we just need lazy evaluation
Bart Lateur wrote: Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, No, that's no good; lazy evaluation was necessitated by functional programming, which of course perl should avoid like the plague... -- John Porter
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote: Someone on this list (TomC?) has supplied a major diatribe against const. Maybe, but I don't see what's wrong with: my $foo :const = 12; A nice, named, lexically scoped constant. The optimizer should be able to make reasonably good use of that. "JH" == Jeremy Howard [EMAIL PROTECTED] writes: JH Dan Sugalski wrote: The syntax is actually: my type $varname; This is in perl 5.6.0. Modifiers go as attributes after the colon: my Dog $spot : constant = new Dog; JH Yes. But what about types and attributes within complex types? JH - Constant refs vs refs to constants? JH - Types of hash (or 'pair') keys and elements? JH - Attributes (e.g. constantness) of hash keys and elements? JH - Ditto for arrays/lists... JH I left this out of v1 of the RFC because I wanted to get some feedback on JH syntax. If we can flesh this out I'll incorporate it into v2. JH Also, do we want to be able to specify types and attributes within a sub JH prototype? It would be nice to guarantee that subs don't mutate particular JH parameters, that certain data will not be aliased, etc, so that appropriate JH optimisations can be done. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Against overloading || and (RFC 20) -- we just need lazy evaluation
At 11:13 AM 8/11/00 -0400, John Porter wrote: Bart Lateur wrote: Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, No, that's no good; lazy evaluation was necessitated by functional programming, which of course perl should avoid like the plague... Why? (And which should we avoid, lazy evals or functional programming?) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 80 (v1): Exception objects and classes for builtins
Chaim Frenkel [EMAIL PROTECTED] writes: "PC" == Piers Cawley [EMAIL PROTECTED] writes: PC The (continue|always|finally|whatever) clause will *always* be PC executed, even if one of the catch clauses does a die, so you can use PC this to roll back the database transaction or whatever else was going PC on and restore any invariants. Err, how does one differentiate between a 'good' entry and a 'bad' entry. Um, if the try block completed without tripping a catch clause then it worked. If it didn't, then it didn't. If you want to be able to have the continue block not unwind on some occasions then have it check the value of $@. PC Note too that we don't need to do any case based magic, we can and PC should use polymorphism for that. Why? Just because? Good OO programming practice. Use polymorphism to replace switches. Then when you subclass one of your classes you don't have to go 'round rejigging the switch statements. -- Piers
Re: RFC 85 (v1) All perl generated errors should have a
At 10:42 PM 8/10/00 -0400, Chaim Frenkel wrote: PS Can this be merged with RFC 80, or do they need to live apart? I believe they do. This portion can independently survive without an exception mechanism. I'm only addressing the "what error did I get". You are addressing the error handling mechanism. Gotcha. =head2 Classification Schemes To be defined. Suggestions welcome. PS I made a start in RFC 80. Have you looked at the current scheme used by lexical warnings? Yes, but it is structured along the lines needed by warnings and I see a poor match for run-time exceptions. -- Peter Scott Pacific Systems Design Technologies
RFC 78 and shared vs unshared modules/data
On Thu, Aug 10, 2000 at 05:46:14PM -0400, Bennett Todd wrote: Today there's no difference. If the proposal under discussion were to pass, and packages' namespaces were to become local to the namespace where the "use" occurred, then perhaps main::whatever could be a common, stable, global that they could use for these rare variables that really need to be common from multiple invokers. There's a strong implication here that we've just made package namespaces heirarchical. I don't disagree (how's that for a wimpy statement?), but think we need to go further. hbrain racingmmmaybe this is a good idea How does this sound -- Modules (packages) should have the option of declaring themselves to be either rooted or relative in the name space. Thus a module which wanted to guarantee it would have one and only one copy in residence could declare itself module foo.pm package foo; # preserves current usage my $var; # only one copy ever exists no matter how many # modules load foo while a relative would do alternative version of foo.pm package foo; my $var; # one copy per instance of loading of foo In either case, main would load it with a simple use foo; and the package has control over what is shared and what is not. One could even have mixes of shared and unshared with package foo; use foo_shared; my $var = "x"; # per-instance copy set $::foo_shared::var = $var; # cross-instance copy set local $::foo_shared::var as $var;# wow! Yes, I like this.
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, Aug 11, 2000 at 03:30:28PM -, Perl6 RFC Librarian wrote:
=head1 ABSTRACT
It is proposed that two new functions, Czip, and Cunzip, be added to
Perl. Czip(\@list1, \@list2, ...) would return a list that interleaved
its arguments. Cunzip($list_size, \@list) would reverse this operation.
I know other languages call it zip, but personally I dislike that name
as zip() is commonly used with reference to compression. Although
I do not have a good alternative.
@a = (1,3,5);
@b = (2,4,6);
@zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
No need for the \ other builtin operators like shift,pop,splice etc dont
need them, zip should not either. It's prototype would be (\@\@;\@\@\@\@\@\@)
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 ?
=head1 IMPLEMENTATION
The Czip and Cunzip functions should be evaluated lazily.
lazily ? why, no other operator does by default (I am asuming here)
Effectively, Czip creates an iterator over multiple lists. If used as
part of a reduction, the actual interleaved list need never be created.
Yes it should return an iterator in an iterator context.
An example I would use is
for my($a,$b) (zip(@a,@b)) {
# code
}
which would loop through both array together.
Graham.
Re: RFC 91 (v1) Builtin: partition
On Fri, Aug 11, 2000 at 03:36:21PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Builtin: partition =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 11 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 91 =head1 ABSTRACT It is proposed that a new function, Cpartition, be added to Perl. Cpartition($partition_size, \@list) would return @list broken into references to sub-lists, each one $list_size in size. =head1 DESCRIPTION In order to work with lists of arbitary size, it is often necessary to split a list into equal sized sub-lists. A Cpartition function is proposed that achieves this: @list = (1,2,3,4,5,6); @partitioned_list = partition(2, \@list); # ([1,2],[3,4],[5,6]) How is this different to you other RFC for unzip() ? @unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6]) Graham.
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
On Fri, Aug 11, 2000 at 04:22:33PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace localtime() and gmtime() with date() and gmtdate() I think to be politically acceptable to all that should be utcdate() Graham.
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
Replace localtime() and gmtime() with date() and gmtdate() I think to be politically acceptable to all that should be utcdate() Me too. Actually, this was my first choice, believe it or not. The problem is, many people on this list claimed that GMT != UTC, and that machine time is only in GMT, making UTC dicey to derive. Feedback on this? Is this true? Do we care? I read about 10 different things on this and they all said something different. Thanks, Nate
Re: RFC 90 (v1) Builtins: zip() and unzip()
I know other languages call it zip, but personally I dislike that name as zip() is commonly used with reference to compression. Ditto, I really dislike zip() and unzip(). They're PC and even UNIX commands on several platforms now, increasing confusion. Here's two names: mix() and unmix(). It's what's happening, right? Just as short too. No need for the \ other builtin operators like shift,pop,splice etc dont need them, zip should not either. Agreed. -Nate
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, Aug 11, 2000 at 10:06:38AM -0700, Nathan Wiger wrote: I know other languages call it zip, but personally I dislike that name as zip() is commonly used with reference to compression. Ditto, I really dislike zip() and unzip(). They're PC and even UNIX commands on several platforms now, increasing confusion. Here's two names: mix() and unmix(). It's what's happening, right? Just as short too. mix() sounds awfully disorderly. interleave()? No need for the \ other builtin operators like shift,pop,splice etc dont need them, zip should not either. splice() would be fine, but... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 80 (v1): Exception objects and classes for builtins
At 10:34 AM 8/11/00 -0400, John Porter wrote: But I'm against the idea of implicit rethrowing in any case. Sure, other languages do it, but perl doesn't, and personally I think it's a better paradigm. We may have to disagree. If you don't have a clause to catch an exception, semantically, it hasn't been caught, so why would you need to explicitly rethrow it? If the implementation needs to catch it anyway, that's the implementation's problem. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 90 (v1) Builtins: zip() and unzip()
I know other languages call it zip, but personally I dislike that name as zip() is commonly used with reference to compression. Although I do not have a good alternative. fold() and unfold()? merge() and cleave()? A
Re: RFC 85 (v1) All perl generated errors should have a
well, if it is only a string, why use . as the separator? use something else like : and no one will try any fancy math tricks on it. Agreed. I like :, it's a common separator. Also, how about just $@-id? Shorter and I would argue the "unique_" is really redundant (id's are usually unique, hence the name "identifiers"). -Nate
Re: RFC 90 (v1) Builtins: zip() and unzip()
On 11 Aug 2000, Perl6 RFC Librarian wrote: its arguments. Cunzip($list_size, \@list) would reverse this operation. [...] 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]) Would it not be more natural to pass the *number* of lists to unzip, rather than the desired length? This way, unzip() would know to pick off elements two-at-a-time, three-at-a-time, etc., rather than having to go through the zipped list, count the elements, divide by $list_size, etc. Unless I misunderstood the example and you wanted the result to be ([1,2,3], [4,5,6]) in which case unzip would not have to do nearly as much work. But then (1..7) would unzip(3) into ([1,2,3], [4,5,6], [7]). Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 90 (v1) Builtins: zip() and unzip()
Andy Wardley wrote: cleave()? Note that cleave is its own antonym! :-) -- John Porter
Re: RFC 94 (v1) Rename @ARGV to @ARGS
On 11 Aug 2000, Perl6 RFC Librarian wrote: @ARGS is a better choice for several reasons: 1. It's closer to a word and so is faster to read [1] 2. It's easier to explain and remember "Your command-line args are contained in @ARGS" 3. When you say "$var = $ARGS[2]" it's easier to glance at and tell what you're getting quickly 4. It makes it more consistent with other word-like Perl vars like $VERSION. 5. There's no expectation that it works like or should be used like C's argv/argc 6. (arguable) This way, $ARGV (name of current file while reading from ) will not collid with @ARGS if sigils were dropped (aka Highlander notation). Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 76 (v1) Builtin: reduce
On Fri, Aug 11, 2000 at 10:51:45AM -0400, John Porter wrote: Damian Conway wrote: More and more I lean towards a scalar-only reduce. Yep! Have you stollen my brain :) Graham.
Re: RFC 80 (v1): Exception objects and classes for builtins
On Fri, Aug 11, 2000 at 10:26:25AM -0700, Peter Scott wrote:
At 10:34 AM 8/11/00 -0400, John Porter wrote:
But I'm against the idea of implicit rethrowing in any case.
Sure, other languages do it, but perl doesn't, and personally I think
it's a better paradigm.
We may have to disagree. If you don't have a clause to catch an exception,
semantically, it hasn't been caught, so why would you need to explicitly
rethrow it? If the implementation needs to catch it anyway, that's the
implementation's problem.
Which is why catch is the wrong word. In perl eval{} (or try) does `catch' the
error
Graham.
Re: RFC 83 (v1) Make constants look like variables
Spinning off from Larrys syntactic comment and Mike Pastores example, how about some of the following: How about any variable created in UPPER case is a constant? Quite restrictive, and likely to screw many things up, admittedly, but it's an easy rule to remember and one which is generally considered good programming practice. ISTR it's what Ruby uses. It works well for all those Perl-provided variables (e.g. $ME) that *should* be read-only, but not so good for those that are supposed to be read/write (e.g. @INC). A
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, Aug 11, 2000 at 06:25:07PM +0100, Andy Wardley wrote: I know other languages call it zip, but personally I dislike that name as zip() is commonly used with reference to compression. Although I do not have a good alternative. fold() and unfold()? People would confude that for fold() in other languages which is like reduce() merge() and cleave()? I think I like interleave() best, but it's too long. thesaurus.com returns [Verbs] lie between, come between, get between; intervene, slide in, interpenetrate, permeate. put between, introduce, import, throw in, wedge in, edge in, jam in, worm in, foist in, run in, plow in, work in; interpose, interject, intercalate, interpolate, interline, interleave, intersperse, interweave, interlard, interdigitate; let in, dovetail, splice, mortise; insinuate, smuggle; infiltrate, ingrain. interfere, put in an oar, thrust one's nose in; intrude, obtrude; have a finger in the pie; introduce the thin end of the wedge; thrust in (insert) [more]. I think I like plow() or maybe just weave() Graham.
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
On 11 Aug 2000, Perl6 RFC Librarian wrote: In the past, Perl has provided access to date and time information through the C library Clocaltime() and Cgmtime() functions. Unfortunately, these functions have several "really bad things" about them: 1. some values are 0-indexed while others are 1-indexed 2. they return massive lists as their only interface 3. minute and second values aren't 0-padded 4. the year has to have 1900 added to it to be correct. While some of these are perhaps understandable, that last one just plain doesn't make Iany sense Number 1 is good for indexing, and number 3 is the way it is because numbers aren't 0-padded -- after all, you didn't write "01." to "04.". (And number 4 is for hysterical raisins, of course.) =head2 Return Values The return values are dependent on the context within which Cdate() is called. For all contexts, the following are the values and their ranges: $hour = 0 .. 24 $min = 00 .. 59 # 0-padded $sec = 00 .. 59 # 0-padded $fsec = 0 .. 1 # fractional seconds per hw clock I assume $hour, $min, $sec would be dual-valued, a la $!, so that $min might be 9 in numeric context and "09" in string context. This would save a string-to-number conversion if I want to calculate with the value of the variable -- Perl wouldn't have to translate "09" to 9 because it *is* already 9. Oh, and what about leap seconds? Shouldn't $sec's range be 00 .. 61? $mon = 1 .. 12# hooray! $mday = 1 .. 31 $year = 1 .. # 4-digit! While you're at the padding job, make $hour, $mon, and $mday zero-padded to two decimal places as well, for consistency. If you say "those who want 04.07. for the Fourth of July can use sprintf", then zero-padding $min and $sec makes no sense to me, either. So, 04.07.2000 03:06:02, please. (If you want to be really consistent, zero-pad $year to four places, though that will give a Y10K problem.) I'm still a little uneasy about C$wday starting with 1 == Sunday, just because Monday seems like the first day of the week to me. But I'm not the one writing the calendars, and it seems silly to only have one value that's 0-indexed. Oh, well. :-) So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan', 'Feb') or qw(dummy Jan Feb)... oh well. =head3 LIST Context A list of date/time values is returned. The ordering and format of these values has been radically changed to reflect what most of us probably view as "ordinary": ($year, $mon, $mday, $hour, $min, $sec, $fsec, $wday, $yday, $isdst, $isgmt, $tz) = date; This ordering follows the predictable pattern of being in increasing granularity and so should be easy to remember. Just think of a computer-esque timestamp: 2000/11/4 12:03:09 The previous ordering follows the predictable pattern of being in decreasing granularity and so is extermely easy to remember. It also has the advantage that it goes from more specific to more general, so if you don't want the general bits (for example, only the time), you just assign to ($sec, $min, $hr) = localtime; . Note that the month, day, and year are not 0-padded. Apparently, neither is hour. And why not, pray? I'd like to see the justification for this decision. 8. Reverted to GMT from UTC since most systems are internally maintained in GMT, not UTC. What's the difference? Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 83 (v1) Make constants look like variables
On Fri, 11 Aug 2000, Andy Wardley wrote: Spinning off from Larrys syntactic comment and Mike Pastores example, how about some of the following: How about any variable created in UPPER case is a constant? Quite restrictive, and likely to screw many things up, admittedly, but it's an easy rule to remember and one which is generally considered good programming practice. ISTR it's what Ruby uses. It works well for all those Perl-provided variables (e.g. $ME) that *should* be read-only, but not so good for those that are supposed to be read/write (e.g. @INC). Or perhaps merely a new identifier, ie: $:pi = 3.1459;# constant pi %:struct = ( # constant struct :Name = 'Jack', # constant key (I got tired of Jane) Age = 32,# mutable key :Birthday = '08/15' ); what about: $!foo = 'immobile';# mnemonic, NOT as in NOT change $'bar = 'unchanging'; # klingon? $.zot = 'static'; Foo for thought. -- Mike Pastore [EMAIL PROTECTED]
Re: RFC 90 (v1) Builtins: zip() and unzip()
Andy Wardley wrote: I know other languages call it zip, but personally I dislike that name as zip() is commonly used with reference to compression. Although I do not have a good alternative. fold() and unfold()? merge() and cleave()? A collate() and ...?
Re: RFC 85 (v1) All perl generated errors should have a
On 10 Aug 2000 22:26:47 -, Chaim Frenkel [EMAIL PROTECTED] wrote:
=head2 Encodings
I have listed some possiblities. But none of these are ideal.
=head3 A unique number
=item As an integer
=item As a floating point number
=head3 Unique String
=head3 Prefixes for all error strings (Shades of Big Blue)
Well, $@ could also contain a structured 'error object' allowing
not only stringification, for
if( $@ =~ /such-and-such-error/ ) {}
situations, but also (somewhat à la VMS):
$@-facility # CORE, module name, whatever
$@-severity # fatal, informational, error, debug...
$@-message# 'file %s not found' (== stringify)
$@-data # an optional hash for additional data
Obviously, to be useful a standard classification of severity levels
(akin to the one in diagnostics) should be used, and it'd be better
if there were some hooks for modules to register unique facility
names; OTOH, perhaps not: the module name *is* it's own unique
identifier :)
/L/e/k/t/u
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
On 11 Aug 2000, Perl6 RFC Librarian wrote: =head1 TITLE Replace localtime() and gmtime() with date() and gmtdate() Since GMT is specific to the UK and UTC (Universal Time, Coordinated) is the global equivalent, shouldn't the names be date() and utcdate()? =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 05 Aug 2000 Last-Modified: 11 Aug 2000 Version: 2 Status: Developing Mailing List: [EMAIL PROTECTED] Number: 48 -- Yours, Jonathan Leffler ([EMAIL PROTECTED]) #include disclaimer.h Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"
Re: RFC 91 (v1) Builtin: partition
The difference is how they group: @unzipped_list= unzip(3, (1,2,3,4,5,6)); # ([1,3,5],[2,4,6]) @partitioned_list = partition(3,(1,2,3,4,5,6)); # ([1,2,3],[4,5,6]) Let me make an observation, having done tons of matrix stuff: We're going to wind up with 200 functions, all of which essentially are doing special types of matrix operations. How about a matrix-like set of functions that interleaves and un-interleaves stuff however you like? matrix x2, @a, @b, @c; # interleave every 2 unmatrix 3x2 @array; # 3x2 list groupings This would be able to handle any matrix construction with a "ROWSxCOLS" notation. If either ROWS or COLS was left out than a * (any number) would be used. Otherwise, the ROWSxCOLS would have to be fulfilled, with: 1. Less data than specified returning an error 2. More data than specified being discarded Not sure I like the names, or the syntax, but I'm sure we need a general-purpose mechanism here to do this. -Nate
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
Jarkko Hietaniemi [EMAIL PROTECTED] writes: s/gmt/ut/ IIRC GMT got obsoleted in the 70s by UT (Universal Time). Officially called UTC, so utcdate would be a better name I think. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 91 (v1) Builtin: partition
On Fri, 11 Aug 2000, Nathan Wiger wrote: Let me make an observation, having done tons of matrix stuff: We're going to wind up with 200 functions, all of which essentially are doing special types of matrix operations. How about a matrix-like set of functions that interleaves and un-interleaves stuff however you like? matrix x2, @a, @b, @c; # interleave every 2 unmatrix 3x2 @array; # 3x2 list groupings This would be able to handle any matrix construction with a "ROWSxCOLS" notation. If either ROWS or COLS was left out than a * (any number) would be used. Otherwise, the ROWSxCOLS would have to be fulfilled, with: 1. Less data than specified returning an error 2. More data than specified being discarded Not sure I like the names, or the syntax, but I'm sure we need a general-purpose mechanism here to do this. -Nate I'm inclined to agree. We have `splice' for arrays and lists, which is kind of like a swiss army knife, with `[un]shift', `pop', and `push' being shortcuts to `splice' methods. I'd imagine we can come up with a similar scheme for matrices and vectors (not bit vectors, more like a slice of a matrix). How about `mop' (matrix op), `swipe', and `wring'? :) It's been a while since matrices for me to make any profound statements here, other than to repeat what Nathan's already said: they need to be flexible and usable for situations like the proposed `partition', `zip', and `unzip'. If we're going to do "heavy" matrices (full support for everything you find in Algebra II) we'd need functions for finding the determinate, multiplying matrices, adding matrices, etc. It almost sounds like it needs it's own struct type. Between this an HOFN (higher-order function notation), it sounds like Perl is starting to become much more math oriented! Maybe they'll start teaching Perl 6 instead of Fortran for CS300, hmm? -- Mike Pastore [EMAIL PROTECTED]
Re: RFC 83 (v1) Make constants look like variables
On Fri, Aug 11, 2000 at 06:36:44PM +0100, Andy Wardley wrote: How about any variable created in UPPER case is a constant? This involves Perl dictating style to the user. Very un-Perllike, IMHO. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
=head2 Date Arithmetic Date arithmetic has been axed from this proposal. Before you get too upset, I had discussions with several people and became convinced that this is something too difficult and bloated to stick in core. An external module would be much better suited to this. We can still make sure this is included with the core distribution. I understand where you are coming from with this but I could do the date arithmetic myself if there was a method to return the date from the object in some generic form. On unix this is seconds from 1970 but the more generic answer is julian date (or modified julian date). The translation of date to modified julian date can be done with one formula (plus adding the fraction of day from the time) [and yes I could put it in a module -- in fact I already have]. The Time::Local module currently has to be used to retrieve time in seconds from localtime() output. Adding a "date to MJD (or seconds)" and "MJD (or seconds) to date" method allows date arithmetic trivially -- this adds code bloat of about 10 lines to the core but allows the date arithmetic to work. $mjd = $date-mjd; $mjd += 52.5; # add 52 days 12 hours to the date $date-mjd($mjd); # or create new date object with this mjd The MJD to date translation is slightly more complicated but the algorithms are well known. (Hatcher 1985, Quarterly Journal of the Royal Astronomical Society, volume 26, page 151). In summary, adding the functionality of Time::Local to this RFC will make date arithmetic possible (although the Time::Local looks to be more complicated than it should be) without adding undue bloat and operator overloading. Adding support for (modified) Julian Date will be much more generic and remove dependency on unix epoch with little extra code. Feel free to tell me to use an external module though. I had to mention it though. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: Against overloading || and (RFC 20) -- we just need lazy evaluation
Bart Lateur [EMAIL PROTECTED] writes: Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, where you have a possibility to create ordinary looking functions (in Lisp, there's no difference between a function and an operator; the less polite name is "prefix notation"); but the calculation of the values of the parameters can be postponed until the time when the sub is already running. In fact, it won't be calculated, unless you invoke it yourself. (How? "eval"?) How is that against RFC 20? I described such a mechanism there... -- Jean-Louis Leroy http://users.skynet.be/jll
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
On Fri, 11 Aug 2000, Nathan Wiger wrote: Adding support for (modified) Julian Date will be much more generic and remove dependency on unix epoch with little extra code. To me, the real question is which date() should we use: $date = date $seconds_since_epoch; # uses time() $date = date $modified_julian_date; # non-Unix This would be fine so long as time() returned an MJD rather than seconds (or another function was supplied for returning the current time). I was not really proposing that seconds should be dropped just that MJD is an alternative (the other difference is that unix time is an integer and MJD has to be a double). If we can make it work, the second one seems a lot more platform-independent. After all, the epoch has no meaning to those on Macs, PCs, or BeOS machines (except maybe historical trivia). Are we agreed that date() should now be based on Julian date? Here's the advantages: 1. Unix-independent (yeah, I love Unix, but...) 2. Allows easy date arithmetic (complex - module) It should be possible to do date arithmetic with the seconds returned by time() $tomorrow = time() + 24*60*60; so the second point is not really an advantage. The main issue is that date() has a method for returning some number such as this that will allow for easy date arithmetic. MJD has a more generic feel. And here's the disadvantages: 1. Unix time() no longer the basis for date Although that really isn't a disadvantage, just a difference. Indeed. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
Buddha Buck [EMAIL PROTECTED] writes: UT and UTC are different scales, ref: http://tycho.usno.navy.mil/systime.html I believe, as reflected on that page, that UT isn't a time scale in and of itself, but a system of them (including UT0, UT1, and UTC as a weird step-child based on TAI with corrections for UT1). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 79 (v2) Perl Compiler is Just Another Pod Proces
Nice. But you need to discuss the initial condition: I'd guess you need an implicit =begin perl before line 1 of each script file, so that scripts that don't pod still work. How about some extensions, which integrate another old perl5 feature? Instead of __END__, how about =begin data Now that works for a single DATA file handle, but we (probably) also need to =end all =begin data which takes two lines, rather than __END__'s one line. So then we speculate about combinations: if "begin", "end", and "handle" were prevented from being pod processor names, we could =begin perl =end perl begin pod =begin perl =end all handle data =end data handle data2 =handle data3 seen by data2 and data3 handles! =end all begin perl This would restrict data from containing lines beginning with =, or at least lines beginning with =end, =begin, =handle, or =for. Could "escape" with \= or == or ??? -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 83 (v1) Make constants look like variables
Please, please, please, PLEASE, let us not replicate the debacle that is C++'s const modifier! Damian
Re: RFC 90 (v1) Builtins: zip() and unzip()
Damian Conway wrote: Note that cleave is its own antonym! :-) I can see it now: @interspersed = cleave(@list1, @list2, @list3) @separated= cleave(3,@interspersed); Now *that's* DWIM! ;-) In fact, perl really only needs one OP: @results = dwim $stuff, @args, %hey; (Well, I guess that's two: the assignment is an op also.) -- John Porter
Re: RFC 90 (v1) Builtins: zip() and unzip()
Note that cleave is its own antonym! :-) I can see it now: @interspersed = cleave(@list1, @list2, @list3) @separated= cleave(3,@interspersed); Now *that's* DWIM! ;-) Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
I kinda like it. It's... intuitive. It makes named sub arguments rather
straightforward, apart from that prefix thing.
Should (name = 'Bart') really stuff 'Bart' into a lexical variable
$name? That's... odd.
Not really. If (name='Bart') is an arg list, it probably stuffs 'Bart' into
a lexical variable already (via an explicit Cmy %args = @_).
I see no connection between 'name' and '$name', but I'm trying
really hard to ignore any similarities.
They're more alike that name and $args{name}, and people cope with that.
They're more alike that *{name}{SCALAR} and \${name}, and (some) people
cope with that too.
You have overlooked one reference: RFC 21, "Replace Cwantarray with a
generic Cwant function", by... you. :-) I understand that a pair would
behave differently in array context (may I call it that?) than in a hash
context.
That's not how I think of it.
The difference is how a hash and an array *interpret* a PAIR that's assigned to
them. The hash unwraps the pair and stores the value under the key. Teh array
just stores the PAIR as a reference (as it would any other type of reference).
What about the current habit of passing arguments using the "-bareword
= $value" syntax, to unprototyped subs? Is this an array or a hash
context? Or does it not matter?
The distinction doesn't exists, so it (probably) doesn't matter :-)
In case you're wondering, I am thinking
about backward compatibility of current modules on CPAN that use this
syntax, whether these would still work under Perl6, or whether they'd
need a rewrite. (ugh!)
p52p6 would handle it (by translating all Perl 5 Cx="y"'s to Perl 6
C'x',"y"'s.
I *must* put this in the RFC!
Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
But won't this cause breakage to existing scripts
No. p52p6 will simply translate:
x = 'y'
to
'x', 'y'
Note that these semantics still support the popular:
sub hash_like_args { my %args = @_; }
But they will break the idiom of
sub list_of_op_value_parameters {
while(my($op,$value) = splice(@_,0,2)) {
# process
}
}
The abovemention translation will cover this too.
Damian
Re: RFC 76 (v1) Builtin: reduce
A better example might be trying to perform join, with reduce eg
reduce __.','.__ $identity, @list
Which would not work for any value of $identity unless you did
reduce __.','.__ shift @list, @list
which is probably a good example why not to require an identity element.
Just to clarify: the proposal does not (and will not) *require* an
identity element.
prototype('CORE::reduce') == '@'.
Damian
Re: Against overloading || and (RFC 20) -- we just need lazy evaluation
Then, we could simply write our own versions of shortcutting AND and OR. The difference would be that it would look like a function, not like an operator. Compare: expr1 expr2 vs. AND(expr1, expr2) but at least, there would be no confusion WRT precedence rules. And people, seeing every other operator overloaded for a particular module, will assume that || and do the right thing too. But they won't :-( This is a real world problem. I have three separate modules -- Switch, Quantum::Superpositions, and Lingua::tlhIngan::pIqaD -- that don't DWIM because I can't overload || and to work correctly. Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
But... would it be possible to exten this proposal so that, if the right
hand operand is an array or hash variable, it will create a reference to
this variable?
That would allow subroutine calls like:
foo('names' = @names, 'size' = 'A4', 'labels' = %labels)
to do the Right Thing.
Did you see my other post on context propagation of \@ and \% contexts
into the right operand slot? I think that solves the problem too.
But I'll certainly think about your suggestion.
Damian
Re: the currying operator
I like the idea of currying, it seems powerful and Perlish in many ways. However, I don't like the currying operator chosen, because of it's ugliness (IMHO), and its potential for ambiguity (human, not necessarily parser). It's not an operator, it's a placeholder. So, here is my proposal to change the operator. from to --- ^_^^ ^2, ^3^^2, ^^3 ^named^^named To me, it stands out better, and is less likely to cause the programmer looking at it to scratch his head and try to figure out if it's an xor or a curry. I did it myself several times, and I consider myself at least a competent programmer. We chose the placeholder notation to be consistent with the scalar notation (but using a ^ rather than a $): scalar placeholder analog $x, $y^x, ^y $1, $2^1, ^2 $_^_ The RFC should probably say that explcitly. Damian Damian
Self-Sorting Containers
I've started talking about "containers" instead of arrays and hashes
since those both tie directly to implementation details, and containers
are abstractions.
A self-sorting container would be easy enough to tie to, most methods
would inherit from an underlying numbered array, except the insertion
methods and the assignment methods would be different, as after every
alteration, extension, push or unshift the new or modified element
would need to be checked for proper placement. Or proper placement
could be defered until someone tries to access the container and done
then (when the sort happens is an implementation issue)
Maybe the hash syntax would be better for sorted containers, just using
the key return order for the sorting.
If hashes normally had a sort method of null, they would work normally,
but you could overload the sort method of any hash with
methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
What is a better syntax for this?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
Re: RFC 79 (v2) Perl Compiler is Just Another Pod Proces
Glenn Linderman wrote: But you need to discuss the initial condition: I'd guess you need . =end all begin perl I like it! This would restrict data from containing lines beginning with =, or at least lines beginning with =end, =begin, =handle, or =for. Could "escape" with \= or == or ??? Yes; I regard that as hardly a showstopper. I mean, as it is, a __DATA__ section can't contain a bare __END__ ... But, um, whatever happened to the fact that pod tokens have to be paragraph-delimited? I think that the "=end foo" line in the following is not noticed by pod processors, but maybe I'm out of it: =begin data =end foo more data =end data Now, I suppose that =data would be a synonyms for =end all begin data, and would be a replacement for __DATA__ -- John Porter
Re: Portable upper/lower case regexp matches
Peter Scott wrote: Perl 5.6.0 has [[:lower:]] and [[:upper:]]. Yes, but this one is worth a digraph. Question is, which one? Currently the free ones are: \F \h \H \i \I \j \J \k \K \m \M \o \O \q \R \T \v \V \y \Y \v \V are being debated on p5p currently. I suggest \i \I, mnemonic with ?:i and /i. I agree. I also think that a web page with a big table of unresolvables and simple (and uncontrolled) vote tallies would be a good thing. Something like Unresolvable AgreeDisagree Dontcare -- All remaining simple300521 10 digraph letters should be [ ][ ] [ ] [opine] conserved -- Quebeq should secede from 20 71 320 the United States [ ][ ] [ ] [opine] --- with a blank at the bottom for suggesting new unresolvables. I bet that at least a twentieth of the people who will read this could set this system up in about the same amount of time that I spent writing this "me too." -- David Nicol 816.235.1187 [EMAIL PROTECTED] :wq
Re: RFC 84 (v1) Replace = (stringifying comma) with =
[EMAIL PROTECTED] writes: : p52p6 would handle it (by translating all Perl 5 Cx="y"'s to Perl 6 : C'x',"y"'s. : : I *must* put this in the RFC! I think most of the RFCs could use a MIGRATION POLICY section, or some such. Larry
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Nathan Wiger wrote: ...if the "key" and "value" builtins were the only ways to get to the data. You should be able to get to the data directly. How about: $array[0].k $array[0].v -- John Porter
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote:
Someone on this list (TomC?) has supplied a major diatribe against const.
DS Maybe, but I don't see what's wrong with:
DS my $foo :const = 12;
DS A nice, named, lexically scoped constant. The optimizer should be able to
DS make reasonably good use of that.
Err, I was addressing the issue of having
const this
this const
sub foo ($name :const)
etc.
A nice way of making a value read-only is lovely. And let it be a
runtime error to modify it.
The caller can easily do a foo eval{$const_item} to remove the
read-only attribute.
Hmm, perhaps we should rename the attribute
:read-only
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Self-Sorting Containers
methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
What is a better syntax for this?
tie %thehashinquestion, 'Sorted', flubber(^a,^b);
???
Damian
Re: RFC 90 (v1) Builtins: zip() and unzip()
In fact, perl really only needs one OP: @results = dwim $stuff, @args, %hey; (Well, I guess that's two: the assignment is an op also.) dwim @results, dwim $stuff, @args, %hey; Can you say 'Lisp'? Damian
Re: RFC 80 (v1): Exception objects and classes for builtins
"PC" == Piers Cawley [EMAIL PROTECTED] writes: PC Good OO programming practice. Use polymorphism to replace switches. Then PC when you subclass one of your classes you don't have to go 'round PC rejigging the switch statements. I haven't used OO in anger. But for me polymorphism is action-at-distance of the worst stripe. Its the cheap and dirty way of doing OO. Let the object determine the calling convention for the method. I see very little reason to have two methods with different signatures. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 05:09 PM 8/11/00 -0400, Chaim Frenkel wrote: Hmm, perhaps we should rename the attribute :read-only Works, though I like "constant" (or const, that's OK) just as much. Might be worth having a way to set things to read-only temporarily, too. Won't help the optimizer, but it could keep some of the more sublte "whoops"es from happening. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Self-Sorting Containers
Damian Conway wrote:
methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
What is a better syntax for this?
tie %thehashinquestion, 'Sorted', flubber(^a,^b);
???
Damian
Compiler will know to pass flubber as ref-to-code instead of
intant eval because (^a,^b) instead of ($a,$b), or is more,
like \flubber needed here?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Damian Conway [EMAIL PROTECTED]:
This RFC proposes the introduction of a new data type -- the Ipair -- and
the co-opting of the = operator to act as a pair constructor. Most existing
uses of = would be preserved.
[etc.]
%hash = ( a=1, b=2, 'c', 3 );
does what it does in Perl 5, but works slightly differently.
Yeah; so what's the point? Will hashes being represented internally
as sets of pairs be somehow more efficient? What's the win?
When a pair reference is assigned (in)to a hash, the pair's key becomes
the hash entry's key, and the pair's value becomes the entry's value
Wasn't there talk of allowing types other than scalars to be hash keys?
If so, then a pair could not be a hash key, except in the singular
assignment
$hash{ $pair } = $val;
but not in something as trivial as
%hash = ( $pair, $val, $pair2, $pair3 );
I could make a more trivial example, but then I expect you to say
that hash assignment will be smarter about inferring an even number
of values in the rhs.
=head2 Pairs and multiway comparisons
Pairs also provide a clean way of implementing multiway comparisons.
It is proposed that when a pair is evaluated in a boolean context, it
would evaluate to the truth value of its key. But when evaluated as the left
operand of a comparison operator, it would evaluate to its value,
Ibut would short-circuit if its key were false.
Has anyone checked how Icon does this?
(Yeah, I know, I should do it myself.)
Here's a counter-proposal: throw out hashes as a separate internal
data type, and in its place define a set of operators which treat
(properly constructed) arrays as associative arrays. It's the
operators that do all the work anyway; the semantic benefit of
a distinct data type is miniscule. And away with pairs: use
arrays instead. Perhaps, along with constant scalars, we should
be able to declare arrays as having a constant size; and a "pair"
would be a predefined alias for "array with constant size = 2".
One benefit is this allows any type to be the "key" of an assoc. array,
with no extra support required in the core; deep and special-case
comparisons can be supplied by the user.
--
John Porter
Aus tiefem Traum bin ich erwacht.
