Re: English language basis for throw
Peter Scott wrote: Only one of them needs to be right. As long as one is right, there is no problem. Right, I was just pointing out that it's harder for people to divine which one we picked without recourse to the documentation. Yes; unfortunately, this problem exists generally, especially wrt Perl. :-/ -- John Porter
Re: error handling and syntax extension
or AUTOLOAD can be defined in terms of Ccatch
and overloaded that way, rather than being its own
kind of magic.
catch "AUTOLOAD-$classname-$polymorphicsignature" {...
Jonathan Scott Duff wrote:
On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
If "catch" can be defined DURING PARSING
and SYNTAX ERRORS are catchable
error handling can be used to define otherwise
undefined syntax, becoming a macro language.
And AUTOLOAD can go away too! :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Useless use of a void in constant context
Re: Dual nature (was Re: Exceptions and Objects)
At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be the same as a return with no
arguments.
But what of RFC 70, which wants the option for exceptions in system calls
to cause program death?
Also I don't like code deciding to do something different depending on a
context that's possibly miles away.
chaim
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
One issue that haven't seen addressed, is how to _not_ have exceptions.
I want to use a core module (non-core can do anything they want) but
I'd like to write it in procedural mode.
try {
$obj-method...
}
catch { }
finally {}
or
$status = $obj-method...
And have both work properly.
PS Yes, I want this too. The method could certainly look to see whether
it's
PS in void context and throw an exception if so; in fact Jarkko suggested
this
PS just now on p5p:
Mental note: in Perl 6 system calls by default should die if their
return value isn't checked.
PS Short of setting some global switch, I don't see how else to do
PS it. However, this doesn't address the issue of functions which return
PS values anyway and signal errors through $!. If we get open() modified
as I
PS and others would like:
PS my $fh = open $filename;
PS how should we distinguish the one that throw()s from the one that doesn't?
--
Peter Scott
Pacific Systems Design Technologies
Re: Towards a reasonable unwinding flow-control semantics.
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote: "PS" == Peter Scott [EMAIL PROTECTED] writes: PS 1. When an exception is thrown perl looks for the enclosing try block; if PS there is none then program death ensues. Err, if there isn't one. Don't throw the exception. Stop processing but don't throw. You are imposing a style on your caller. ??? I don't get this at all. A message would be appropriate (ala, die or warn) Also a use (within main or if it can work lexically) that would mean die_if_exception_thrown. Would treat the main routine as if it were wrapped in a try block that doesn't catch any exceptions. RFC 63 already states this. Uncaught exceptions at the outermost level are dies. (And there is a very close relationship between die and throw.) -- Peter Scott Pacific Systems Design Technologies
Re: yoda 2
"DLN" == David L Nicol [EMAIL PROTECTED] writes: DLN =head2 eval/die remains perfectly workable DLN as "die" is a perfectly serviceable method or raising an exception. Actually, die is pretty nasty. Modules can't use it. Another mechanism that means, short circuit, but let the user know why. That selects either a non-local goto or a return mechanism depending upon context. (Dynamically within the control of a try/eval, or under pragmatic control requesting the non-local mechanism.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Dual nature (was Re: Exceptions and Objects)
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be the same as a return with no
arguments.
PS But what of RFC 70, which wants the option for exceptions in system calls
PS to cause program death?
PS Also I don't like code deciding to do something different depending on a
PS context that's possibly miles away.
That would be a choice of the main program, Either wrap itself in a try.
or a pragma that probably would look nicer.
Actually, this would be no worse than any other perlian context. If
the effect of a scalar context could make a remote literal ',' become
a comma operator, than this can't be any worse.
Another way to look at it, is that it _doesn't_ effect the callee. The
callee wishes to terminate the function, and the next
statement/expression will not be executed. The callee supplies the
result. The caller is deciding how the results will be delivered.
Hmm, I'm sure that some authors who like the error return style would
like the pragma to force return context so that they don't have
to wrap everything in a try.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Towards a reasonable unwinding flow-control semantics.
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS 1. When an exception is thrown perl looks for the enclosing try block; if
PS there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing but
don't throw. You are imposing a style on your caller.
PS ??? I don't get this at all.
Consider a module A uses try all over the place. Module B uses procedural
call, and accepts callbacks from A.
The callbacks from A raise/throw around B. B's author would like to
be able to do some cleanup, restore invariants, whatever, after a
callback fails. By allowing the caller to determine how the errors
are delivered we are allowing the author more freedom in his design.
So all he would need to add would be a lexical pragma, use exception 'return'
A message would be appropriate (ala, die or warn)
Also a use (within main or if it can work lexically) that would mean
die_if_exception_thrown. Would treat the main routine as if it were
wrapped in a try block that doesn't catch any exceptions.
PS RFC 63 already states this. Uncaught exceptions at the outermost
PS level are dies. (And there is a very close relationship between
PS die and throw.)
But I don't want that. Why? Throws are error returns not death.
A module author should _never_ invoke die. How does the module author
know what the caller wants to be done.
I just don't want to be forced into scattering lots of little try{}
just to get back to my error return style of coding.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 63 (v3) Exception handling syntax
Peter Scott wrote:
If that were so, even without the ignore() function, I could just say
sub Exception::IO::throw { 'do nothing' }
and kill it that way.
Right. Just like overriding core die. At that point you can
change the semantics in such a way as to turn your code into
nonsense.
I am open to suggestions on whether we should make it impossible for
someone that determined to shoot themselves in the foot to do so. My
feeling is that someone smart may have a good reason for doing it (in
their own code, not in a module given to others), and someone dumb
deserves what they get for doing something so blatantly stupid.
I agree, we should not make it impossible, but I believe we should make
it relatively difficult to do accidentally (much like the forgotten
re-throw or function return code checking problems).
Yours, c, Tony Olekshy
Re: Towards a reasonable unwinding flow-control semantics.
Executive summary: I no longer want catch blocks to "daisy chain"
after a exception is thrown in a catch block. Thanks to everyone
who has helped me see the light on this.
Peter Scott wrote:
At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
The proposed omnibus Exceptions RFC uses the following three
rules to guide it while unwinding through the clauses of a
try statement.
Forgive me for eliding your explanation, but I find it a little
opaque
Me too, that's why the subject contains the word "Towards".
Let me advance a model which may be simpler.
1. When an exception is thrown perl looks for the enclosing
try block; if there is none then program death ensues.
2. If there is an enclosing try block perl goes through the
associated catch blocks in order. If the catch criteria
succeed (the exception class matches one in a list, or a
catch expression evaluates to true, or the catch block
catches everything), the catch block is executed.
If the catch block throws an exception, it becomes the
'current' exception (with a link to the previous one),
otherwise there is no longer a current exception.
3. Whether or not a catch block was executed, the finally
block is now executed if there is one. If the finally block
throws an exception, it becomes the 'current' exception
(with a link to the previous one if there was one). At
this point, if there is a current exception, go to step 1.
This seems complete and IMHO easily understood.
Yes, that's much better. Thanks Peter. Here is a slightly
different version which is still slightly more complex, but
which allows me to more clearly illustrate the change I am
proposing.
1. Whenever an exception is thrown it becomes the current
exception (with a link to the previous one if there was one)
and Perl looks for an enclosing try/catch/finally block.
If there is no such enclosing block then program death ensues,
otherwise Perl traps the exception and proceeds as per rule 2.
2. The relevant try block's next associated catch or finally block
is processed according to rules 3 and 4. When there are no
more blocks use rule 5.
3. If the criteria for a catch succeed (an exception was thrown
and either the exception class matches one in a list, or a
catch expression evaluates to true without throwing, or the
catch block catches all exceptions), the catch block is
executed.
If the catch block and its test expression do not throw then
the current exception is cleared. Otherwise, the exception is
trapped and it becomes the 'current' exception (with a link to
the previous one).
Processing continues with rule 2. [But see below --Tony]
4. When a finally block is encountered it is executed.
If the finally block throws an exception it is trapped and it
becomes the 'current' exception (with a link to the previous
one if there was one).
Processing continues with rule 2.
5. After the catch and finally blocks are processed, if there
is a current exception then go to step 1. Otherwise continue
with the statement after the try statement.
My question is: where should processing continue after rule 3?
The version shown above produces the problem I described before:
try { } except { } = catch { }
except { } = catch { }
catch { }
The potential problem is that if the first catch throws, then
the second except will be testing against the $@ from the catch,
not the $@ from the try.
Is this a problem?
Yes, I think it breaks the intuitive model.
I do too, so the question is what to do about it. I propose changing
rule 3 to add the new paragraph marked with **:
3. If the criteria for a catch succeed (an exception was thrown
and either the exception class matches one in a list, or a
catch expression evaluates to true without throwing, or the
catch block catches all exceptions), the catch block is
executed.
If the catch block and its test expression do not throw then
the current exception is cleared. Otherwise, the exception is
trapped and it becomes the 'current' exception (with a link to
the previous one).
** If a catch test succeeds (or throws), then whether or not the
** catch block throws, any succeeding catch blocks up to the next
** finally block are skipped.
Processing continues with rule 2.
This probably means that it should be a syntax error to have any
catch clause follow a non-conditional catch, because such a clause
could never be executed.
throws() outside a try block are caught by the catch
blocks of the next enclosing try block. See above.
Not quite. Throws in a catch block (not a try block per se) still
have to be trapped in order to get to the finally block, if any.
I think you probably meant that, I'm just making it explicit.
The change I described above would get the
Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.
Peter Scott wrote:
Tony Olekshy wrote:
[snip]And the following output was generated:
Exception
$ = Try::throw('Exception') called from scott2.pm[8].
$ = main::pling('Test') called from scott2.pm[4].
$ = main::bar('Test') called from scott1.pl[1].
$ = main::foo('Test') called from scott1.pl[8].
$ = Try::try(CODE(0xca8830)) called from scott1.pl[9].
$ = Try::try(CODE(0xca2418), 'catch', CODE(0x10b18ac))
called from scott1.pl[8].
If I'm not mistaken, exceptions must bubble up through the call
stack as at the point the exception is thrown, so if we capture
that stack traceback then, we have all the info. Do you still
want the file/line array?
Yes, I want to be able to get at it Ccaller-like. You're just
dumping it.
Ok, but that's just because I was storing it in a string. Instead
of going to all the trouble to format up the string, we can copy
some of those caller fields into an array (one entry per level) of
hashes (one key per value). Like this:
$myException-{stackTrace}-[0]-{file}
$myException-{stackTrace}-[0]-{line}
$myException-{stackTrace}-[0]-{sub}
Yours, c, Tony Olekshy
Re: Towards a reasonable unwinding flow-control semantics.
On Wed, Aug 16, 2000 at 11:49:03AM +0100, Graham Barr wrote:
if any of the catch or finally throws, it is caught by a
try {} block up the stack.
Keep It Simple
What he said.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: Try? There is no try. -- Yoda's Exception handling syntax
I do not know what advantages the try statement would have in perl. However, in Java programming it makes exception handling more explicit. It basically allows the programmer to "try" a certain action and see what the effects are going to be (i.e. handle the exception) so that some action can then be taken based on the results of the exception. If no exception happens then the code did exactly as you expected. If not, then perhaps the action was not appropriate for that peice of code. This can be useful in an OO application. - Bradley S. Behrens -Original Message- From: Graham Barr [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 16, 2000 3:23 AM To: David L. Nicol Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: "Try? There is no try." -- Yoda's Exception handling syntax On Tue, Aug 15, 2000 at 08:11:55PM +, David L. Nicol wrote: Would someone please enlighten me as to the purpose of an explicit "try." In my mind it allows the important code to come before the "oh crap something went wrong" code. Graham.
Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.
[EMAIL PROTECTED] (Tony Olekshy) wrote on 15.08.00 in
[EMAIL PROTECTED]:
What if we implemented something like the following?
Seems that the basic unwinder is
except { ... } = catch { ... }
and everything else can be written in terms of this:
catch { ... }
except { 1 } = catch { ... }
catch "ClassName" { ... }
except { $@-isa($ClassName") } catch { }
finally { ... }
except { 1 } = catch { ... ; throw $@ }
MfG Kai
Re: RFC 120 (v1) Implicit counter in Cfor statements, possiblyC$#.
On 16 Aug 2000, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implicit counter in Cfor statements, possibly C$#.
=head1 VERSION
Maintainer: John McNamara [EMAIL PROTECTED]
Date: 16 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 120
However, the latter format is often more convenient if you need to keep track of the
array index as well as iterating over the array:
for ($i = 0; $i = $#array; $i++) {
print $array[$i], " is at index ", $i, "\n";
}
is more succinct than:
$i = 0;
foreach $item (@array) {
print $item, " is at index ", $i, "\n";
$i++;
}
What about:
for (0..$#array) {
print $array[$i], " is at index ", $i, "\n";
}
I use that whenever I need to loop over indices of two arrays at once.
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
RE: Try? There is no try. -- Yoda's Exception handling syntax
-Original Message-
From: Barrie Slaymaker [mailto:[EMAIL PROTECTED]]
[EMAIL PROTECTED] wrote:
It basically allows the programmer to "try" a certain action and see what
the
effects are going to be (i.e. handle the exception) so that some action
can
then be taken based on the results of the exception.
Seems like any BLOCK could be an implicit eval {...} or try {...}, with the
exception handling stuff triggered by following catch or (finally|cleanup)
blocks:
{
kaboom ;
}
catch blah {
}
cleanup {
}
This is like BLOCKs-as-loops. Personally the extra 3 or 4 letters to spell
eval or try don't matter that much to me, and it would make some folks feel
more at home. Though they could be optional, like 'return' before the
final
expression in a sub.
I like this. M so sweet.
Let me see If I have it...
try {...} is synonmous with eval {...} which is syntatic sugar for { ... }
any / all of which can:
contain Cthrow statments
be followed by (one or more?) catch blocks to evaluate code only if
somthing got tossed by the block
be followed by one (or more??) finally blocks containing code to be
evaluated
requardless of the result of the qw(try eval anon) block
So the changes, as far as diction is concerned would be:
New keywords:
try(same as eval)
catch (same as Celse, or maybe Celsif)
finaly (same as {...})
throw (kinda like Cdie)
The catch being that throw does some stack preservation specialness, and
probably pushes some info onto an exception stack for later unwrapping when
main goes and tries to explain what happened.
So what am I missing (please not everyone at once ;)
-Corwin
Re: Try? There is no try. -- Yoda's Exception handling syntax
[EMAIL PROTECTED] wrote:
It basically allows the programmer to "try" a certain action and see what the
effects are going to be (i.e. handle the exception) so that some action can
then be taken based on the results of the exception.
Seems like any BLOCK could be an implicit eval {...} or try {...}, with the
exception handling stuff triggered by following catch or (finally|cleanup)
blocks:
{
kaboom ;
}
catch blah {
}
cleanup {
}
This is like BLOCKs-as-loops. Personally the extra 3 or 4 letters to spell
eval or try don't matter that much to me, and it would make some folks feel
more at home. Though they could be optional, like 'return' before the final
expression in a sub.
- Barrie
Re: Line disciplines (was Re: RFC 69 (v3) Standardize input record separator)
I'll try to scrap and rewrite the RFC this weekend. $/ = qr/[\r\n]/f; # fast ? How about we use the specialized DFA regex, but also slightly different notation? -Hao
Re: RFC 14 (v2) Modify open() to support FileObjects and
Chaim Frenkel [EMAIL PROTECTED] writes: What about native extensions? I think VMS (and the old TOPS10) had versions as part of the file name. Do URIs have this capablity? And what does a read of a directory return? URIs or Native? Relative URIs I assume - what are (hopefully) indistinguishable from native in the UNIX case at least. -- Nick Ing-Simmons
Re: RFC 30 (v2) STDIN, STDOUT, and STDERR should be renamed
Michael Fowler [EMAIL PROTECTED] writes: On Sat, Aug 12, 2000 at 08:49:00AM -, Perl6 RFC Librarian wrote: In addition, this RFC recommends deprecating select(), since it is no longer needed with the new fileobject approach described in RFC 14. You should probably mention here that the single-arg form of select() is the one you're suggesting for deprecation, and not the four-arg form. The 4 arg form will be deprecated somewhere else. Splitting the function is a good idea... -- Nick Ing-Simmons
Re: RFC 100 (v1) Embed full URI support into Perl
So, what's so portable about file:// URLs again? How do they magically know that //c/ means / on UNIX? What do they do with //z/? This is only one example. I'm not sure it's the best way. It's definitely not the only way. Chaim asked: Or for that matter "file://u/frankeh/Projects" become? (I happen to live at a mount point /u. You're missing an / under the example I showed. And extra / would specify root explicitly. But we're getting too tied up into details on this already. It's only one of many many suggestions for portably dealing with filenames. URI support has many advantages in its own right. For one thing, It allows this: $fo = open "+ http://www.yahoo.com/"; print $fo $query_string; $result = $fo; To: 1. automatically fork http-open 2. create a POST on yahoo.com 3. read the results back from the POST Have you ever used LWP? It's already "really cool". Should we package it with Perl6? Sure! Should we try to cram its many protocols into open? I'm not so sure. Please read RFC's 14 and 101. Nothing is getting crammed into open. Rather, open() is providing a portable mechanism for new file types and methods to be easily accessed. Please read the RFC, it will help clear this up. If you want to wait, v4 should be out tomorrow, which should be even better. -Nate
Re: RFC 30 (v2) STDIN, STDOUT, and STDERR should be renamed
Graham Barr wrote: Create a new handle, like $DEFOUT. Then there would be no need for selectsaver either as you would do the equiv. of local($DEFOUT) = $newhandle; Just submitted an RFC on this exact idea. -Nate
Re: Eliminate dynamic variables entirely?
Kai Henningsen wrote: 1. Package variables $package::var, presumably you'd have to declare those and the default would be 2. lexical variables, Not bad, but I think #1 violates Laziness if I hear you right. Let's add a "global" or "your" keyword to do this inside a package: package MyPackage; our $var = 'val'; # package-wide, lexical your $VAR = 'val'; # package-wide, global, $pkg::VAR If this is what you meant, nevermind... Furthermore, in the "more rope" department, it might be possible to make local() work on my() variables this way. I'm still unsure if this is a good thing. I think it is, but it's worth some pondering. -Nate
Re: RFC 97 (v1) prototype-based method overloading
Damian Conway [EMAIL PROTECTED] writes: Why would anyone want to select a different method based upon the arguments. Have you seen Class::Multimethods? This kind of despatch can be very useful. Of course, the existence of Class::Multimethods proves that it can be done already so there may be no need to put it in the core. There's a definite need to put it in the core. Class::Multimethods is too slow. I'll be proposing this form of multiple dispatch and overloading in a forthcoming RFC. Oh, I don't doubt it. My point was that if it *doesn't* get in then it won't be the end of the world (and hopefully there will be improvements in basic dispatch speed that will mean that the multiple hit on the dispatch system entailed by Class::Multimethods won't be quite so gruesome). I'm in the camp that would rather see it in core though. -- Piers
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Tue, Aug 15, 2000 at 11:46:04PM -0400, Stephen P. Potter wrote: Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). One of them has implicit key, the other has an explicit key. They both provide some sort of ordered collection (plural), even if it is difficult to understand what the order is of hashes. Seems to me we could eliminate arrays and just keep hashes. Arrays are ordered. Hashes are not. Sure, you can iterate over a hash, but add an element to one and you can change the order of everything in it. You are guaranteed that won't happen with an array. Looking up a value in an array is faster than doing so with a hash. Appending a value to an array is usually faster than adding an element to a hash, but inserting elements into the middle of a large array will generally be slow. Hashes consume more space than arrays containing the same number of values. Plenty of other differences. Sure, most of them are connected to the implementation and efficiency, not the abstract concept of arrayness and hashness -- but Perl is a Practical language, and practical programmers like to know these things. You can change a lot of these things by twiddling with the internal implementations, but at the end of the day "ordered set" and "mapping" are conceptually and practically different beasts. I don't think there is any reason for Perl to want to toss away the distinction. - Damien
Re: Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)
On Tue, Aug 15, 2000 at 10:26:13PM -0600, Nathan Torkington wrote: I like the idea of adding the context-aware operators, but I don't think I'd use them as often as I use "the number of things in the array". I think most Perl programmers would be in the same camp. Unless you can show a couple of cool things that this makes possible, that is. So I'd say: option, yes. Default, no. I also like the idea of context-aware operators. I don't know if I like them enough to want to break with former practice, but I do know that I don't like the idea of making them optional. This would be the mother of all action-at-a-distance hells: set_size(@elts * 5); # size = Five times the number of elements. set_size(@elts * 5); # $size = The number of elements -- someone # turned on context-sensitive operators, # 2000 lines above here. I don't know what the right thing to do is. Context is crypto enough these days, without shifting the rules on operator contexts around. Perhaps the benefits outweigh the breakage that will occur. - Damien
Uses for array notation (was Re: RFC 104 (v1) Backtracking)
Mark Cogan wrote:
At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
It seems obvious that @a should be the whole array @a, not the size of
the
array. If I want to check the size of @a, I should have to do so
explicitly,
with scalar or $#.
This is non-obvious if you think that || is a flow control statement, so
think about * for a moment:
@c = @b * @a;
But, to me at least, arrays aren't something you multiply. Multiplication
applies to numbers (scalars), and returns a scalar, so when you see
@c = @b * @a
it should be clear that something funny is going on.
Well, they're not something you multiply in Perl now. But there's plenty of
languages where you can, and it's ever so convenient.
And, really, what is wrong with:
@c = map {$a[$_] * $b[$_]} (0..$#a);
Numerical programming is all about manipulating arrays (or n-dim tensors,
but they're just order array slices really). Writing such programs in a
language that requires explicit loops is not only a pain, but creates code
that bears no resemblance to the numeric algorithm it's implementing.
Furthermore, it's out of the question in anything other than low-level
languages, because the looping and array dereferencing is much too slow.
It also makes easy things easy:
@full_names = @first_names . @surnames;
and with the extension to scalars as one operand (coming in v2!):
@quoted_lines = ' ' . @raw_lines;
or
@histogram = '#' x @num_recs;
It's pretty clear what working on 'the whole array' means here, I think.
I disagree. In particular, think of it from the point of view of someone
who hasn't studied computer science.
What should:
@a = defined @a;
return?
defined() is a function. Under the proposed extension of RFC 82 from
operators to functions, this example should return a list of booleans, where
each is true if the corresponding element of the original list was defined.
Under Perl 5.6, 'defined @a' is deprecated. This RFC would give it a useful
meaning (in a list context).
Treating || as a special case is asking for trouble. If you want a flow
control statement, use one:
@result = @b unless @result = @a;
|| may be a suboptimal example, but I think the idea that a @-variable
without an iteration function refers to the array as a whole, and not its
elements is an intuitive one, and having array iteration magically happen
when you're not looking is dangerous.
It seems funny if you're not used to it. But that's because we learn that
lists are hard, and computers have to loop. After just a little unlearning
it actually becomes quite intuitive, and is generally picked up with no
additional trouble by new students. Programmers shouldn't have to know how a
computer implements things behind the scenes--which is really what requiring
explicit looping forces.
Re: RFC 82 (listops in list context)
At 04:02 PM 8/16/00 +1000, Jeremy Howard wrote: Nathan Torkington wrote: Your [Jeremy's] RFC says: Currently, operators applied to lists in a list context behave counter-intuitively: Counter-intuitively is different from consistently. Your title is misleading. Perl's ops *are* applied consistently: they consistently give their arguments scalar context (except for the short-circuiting logops, which I'd like to fix by making them return the useful lists instead of possibly a list or a scalar). You're right. If RFC 45 is implemented they would however be inconsistent. No, || is half-consistent at the moment: the left hand side is forced into scalar context but the result context propagates down the right hand side. I challenge anyone to come up with a rationalization for this that does not invoke implementation expediency. Anyway, I'll change the title in the next version. The proposal to handle functions is tricky, since there is currently no obvious way to see whether a function is going to return a list. Either we need some kind of more advanced prototyping (or other way of creating a signature), or we need to manually change functions provided with Perl to check for list context and Do The Right Thing. I assume you're talking about: @r = func1() + func2(); No, I'm talking about: @r = abs(@r); I know what you want that to do, and even though I haven't wanted to do that since I was writing a 3-D object manipulation program in PerlTk I can appreciate the elegance of it; but it just don't read right to me at first glance. This is like trying to define obscenity: some ends of the spectrum are pretty clear: @a = @b * @c; clearly reads as matrix multiplication. This is a 1958 Playboy cover. @a = @b ? @c : @d; Making *that* distributive would be something written on a bathroom wall at Venice beach. In between we have @a = @b || @c; which goes according to taste. Mebbe a slightly cleaned-up version of Flesh Gordon (which has been airing on the Space Channel in Canada, but would never see the light of day on the equivalent cable tier in the US). -- Peter Scott Pacific Systems Design Technologies
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Damien Neil [EMAIL PROTECTED] writes: Arrays are ordered. Hashes are not. Sure, you can iterate over a hash, but add an element to one and you can change the order of everything in it. Formally, I believe it's permissable for a hash implementation to return a different order the second time you iterate through it from the first time, even if you haven't touched the hash inbetween. That's the definition of an iterable but unordered data structure; there's some way of getting all of the members one and only one time, but each time you look at it the order in which the members show up may be different (maybe garbage collection happened behind the scenes, the hash was reorganized due to an observation of how you were using it, etc.). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Array notation (was Re: RFC 104 (v1) Backtracking)
Mark Cogan wrote:
At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
You are missing the beauty of vector/matrix operations.
No, I'm not; I'm opining that the vast majority of Perl users don't need
to
do vector/matrix ops, and that they don't belong in the core.
The vast majority of Perl 5 users don't, because it's a pain in Perl 5. They
use other languages instead, but those other languages aren't nearly as nice
as Perl in almost every other way. Why not open up Perl for a whole new
class of folks?
The math folks
really would like to be able to describe the operation wanted and have
perl do the optimization.
Then maybe they should use a dedicate math extension to Perl, like PDL.
You've got to be joking! You think PDL is a simple convenient add-on to Perl
that provides these features? It's not! PDL is an astonishing hack by some
incredibly clever people, but it still _does_not_ support array notation,
and optimised loops have to be written in yet *another* language named PP,
which is compiled into C by a special compiler, and linked into the program.
This is the absolute best that can be done right now, and the PDL folks
deserve a medal for what they've achieved. But really, no-one should have to
jump through these kinds of hoops!
Would adding another character be helpful
@result = @a x|| @b?
@result = @a ||| @b?
or perhaps a modifier?
@result = @a || @b forall;
(Blech, that just doesn read right.)
Perhaps we just need a two-list map, which aliases $a and $b like sort():
@result = map {$a || $b} @a,@b;
No. It would need to be n-list, and it would have to handle slices and
lazily generated lists incredibly cleverly. map is too generic to easily
make the kinds of optimisations required for array notation.
I don't know how to convince you here. There's a feature that, if added to
Perl, would make my life and many of my collegues lives easier. I know this
for a fact because I've used it elsewhere. I doesn't break much that can't
fairly easily be incorporated into P52P6, it's a generic abstraction that
applies to many things other than numeric programming (it's great for string
manipulation!), and it's proved itself elsewhere.
I'm not ruling out a modifier, as Chaim outlined, although I agree that the
word 'blech' comes to mind. But this is too good an opportunity to see it
just disappear. Have a look at the examples in RFCs 23, 76, 81, 82, 90, and
91, which combine together to provide as strong a data manipulation language
as you'll find anywhere. Over the next few days I'll be updating these to
include more examples, particularly non-numeric ones.
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Please take this discussion to perl6-language-datetime. Thanks! K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: list changes: perl6-language-objects added, perl6-language-unlink closed
On Tue, Aug 15, 2000 at 09:27:23PM -0700, Ask Bjoern Hansen wrote: LIST: perl6-language-objects CHAIR: Nathan Wiger [EMAIL PROTECTED] MISSION:Develop RFCs related to objects and OO programming in Perl, possibly rationalising existing RFCs where they cover the same ground. DEADLINE: As long as it takes. Report fortnightly (first report August 29th). Nathan, as a first task, could you figure out a list of which existing RFCs belong on the -objects list? K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Language WG report, August 16th 2000
OK, weekly report. Ugh. The language group has generated the vast majority of the 100+ RFCs in existence, and is suffering under the deluge of 100-200 posts a day. I would prefer this to be down around 50, but no luck yet :-/ Part of the problem seems to be timezone related... the lag time between an RFC being posted, me seeing the thread and realising the need for a sublist, and Ask actually creating that list, means that you get 2-3 days of traffic before it can be moved elsewhere, and a single RFC can easily generate 50 posts. Several sublists have been spawned, but we're not sure how successful they are yet. They seem to have low traffic, which could mean that they simply aren't working (because nobody wants to use them), or that they *are* working (because the people previously discussing the subject on -language weren't deeply interested and just joining in for the hell of it, and the sublists scare off the dilletantes). I think that an NNTP interface would be *seriously* useful to the sublists. Discussion over dinner with Melbourne.pm gave me a whole bunch of things to pursue, including: - co-operation between the language and stdlib groups (co-operation with internals is pretty good already, mostly due to Dan's involvement in both camps) - need to talk more to the PDL/numeric Perl/etc people and figure out how best to get that group working well within the language WG - a few thoughts on RFC format (already posted) There are a bunch of other little bits and pieces, mostly related to individual RFCs, which I'll be following up with the RFC authors by personal email over the next few days. I got a lot out of talking with Damian and Jeremy face to face over dinner last night, and would like to repeat that on a semi-regular basis. It also reminded me that I should talk more to Nat and Dan and probably other WG heads... can we set up weekly IRC meetings, at least? K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
Nathan Torkington wrote:
Not every subroutine corresponds to a method call exposing
object-internal data. Most of my subroutines *do* something and make
no sense to be called lvaluably. Explicit marking the compiler pick
up assignments to non-lvaluable subroutines. It makes sense to
explicitly mark the rare cases (:lvalue), rather than the common
(:no_assignment).
Well, this argument makes more sense. However, I still have to disagree.
In fact, I think the opposite: ALL subs *should* be lvaluable by
default. Here's why.
One word: CPAN (ok, an acronym :). Let's take CGI.pm as an example.
Currently, you can do this:
$val = $cgi-param($name);# get the param
$cgi-param($name, $val); # assign a val
So, it seems the next logical extension would be this:
$cgi-param($name) = $val;# assign a val
No problem. In fact, this fits under your rules. HOWEVER, it also
assumes that Lincoln thought that param() was :lvalue-worthy. What if he
forgot? Or didn't think of this case?
Worse, what if a somewhat novice writes a module and doesn't know about
:lvalue, or at least not how to use it. But an experienced user picks up
their module DoCoolStuff.pm on CPAN and tries it:
use DoCoolStuff;
$dcs = new DoCoolStuff;
$dcs-main_matrix_name = "Bob";
Ooops! The author didn't use :lvalue. So even though this makes perfect
sense to be able to do, since the author forgot to use :lvalue, you lose
a really cool syntactic tool. This seems backwards. I, the user, want to
make this decision. There's no way a module author can possibly forsee
all the uses of a function, and they shouldn't have to.
Having lvalue subs that work just like rvalue ones is an invaluable
tool. This RFC is right on. The only way, though, that it's going to be
useful is if it works just like other assignment: automatically and
pervasively. For one thing, you can do this:
@array = $r-func((split /:/, PASSWD));
Why not this?
@array = ($r-func) = split /:/, PASSWD;
Might look weird at first, but it's not. It's just like any other
assignment. This surely doesn't look weird:
@array = ($r-{func}) = split /:/, PASSWD;
And it works just fine in default Perl 5 with no special keywords. No
reason that dropping two {}'s should change this. If it does, then we're
losing valuable OO encapsulation and abstraction. In fact, a lot is
gained in making lvalue subs the default, because it makes things more
reliable and consistent.
lvalue subs are worth a lot more than just simple data accessor
functions. I don't see why we should force-relegate them to a background
role by requiring an :lvalue constraint that most people won't
understand how to use correctly. This is a perfect opportunity to make
an easy thing even easier.
-Nate
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
"Randal L. Schwartz" wrote: What would be NICE is to treat @stonehenge here as *always* a variable So, I'd support a modification to the RFC that does what Larry intended here: array interpolation should work exactly like scalar interpolation That was actually the intent of the RFC, but I'll update v2 to make it clearer. Thanks, Nate
Re: RFC thoughts and guidelines
(reply-to set to bootstrap) On Wed, Aug 16, 2000 at 01:36:47AM -0600, Tony Olekshy wrote: On this matter, should something like this be a (meta) RFC? Guidelines for Developing Changes for Perl 6 (v0.1). There's nothing to stop you writing an RFC on whatever you like :) However, there's nothing making anyone implement or follow the guidelines you set out, so an RFC phrased as yours is will probably not actually go anywhere. More useful might be an "approach" type RFC saying "Perl 6 should take this approach", and referring to RFCs which you believe are related by merit of following that approach :) K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 76 (v1) Builtin: reduce
Nathan Wiger [EMAIL PROTECTED] writes: Jarkko Hietaniemi wrote: The $a and $b of the sort comparator were A Bad Idea to begin with. Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't be used, or even a more standard $1 and $2. Either one makes it more obvious what's being operated on. $1 $2 could be somewhat dangerous in a sub that might have regexen in it...
Re: RFC 104 (v1) Backtracking
There's also the cut operator which I didn't see mentioned in the RFC.
It blocks backtracking so that something like this:
B1 andthen B2 andthen cut B3 andthen B4 andthen B5
wouldn't backtrack to B2 once it forwardtracked to B3.
]- I tried minimalistic approach as small as possible additions to the Perl
language, we get only the "backtrack" mechanism i.e. something that is
harder or slower to be done outside of the perl core.
The rest should be done outside . (I too want all in the core)
Example :
my $cutState = 0;
{
{ block1 } andthen { block2 } andthen { block3 } andthen
if ($cutState) { last AFTER}
else { $cutState = 1}; 1;
}
andthen { block4 } andthen { block5 };
}
AFTER:
code
not sure will this also do the job :
{ $cutState = $cutState ? last AFTER : 1 } .
So the CUT is candidate for module. Offcourse I preffer all syntax to be
embeeded, cut,fail ... but if I tried in this way there is smaller chance
this to get in the core ..
Think, it is only around 10 lines of code to be added in perly.y i.e. 10
lines C code in Perl-core.
Mainwhile CUT is small too :")
Okay, the more I think about it, the more I think it should be a
module.
]- How this can be done as module ?
=
iVAN
[EMAIL PROTECTED]
=
Re: RFC 104 (v1) Backtracking
They behave similarly like , ||, and, or operator with one main
distinction they "backtrack" for example:
{ block1 } Bandthen { block2 };
This would be a good use of the to-be-liberated = operator:
{ block1 } = { block2 };
In any case, "andthen" doesn't seem like a good choice.
Other possibilities:
therefore
implies
segue
seq
so
]- any proposal for the name are welcomethey must be two. the
reason I decided to use this is cause it works like/is similar to -
if-then-else, also look like and/or comparions operator.
The Prolog operators "," and ";" are already overused in perl.
THEN is not used by PERL, so here comes :
AND+THEN
OR+THEN
:")
=
iVAN
[EMAIL PROTECTED]
=
Re: RFC 104 (v1) Backtracking
raptor wrote: ]- I tried minimalistic approach as small as possible additions to the Perl language, we get only the "backtrack" mechanism i.e. something that is harder or slower to be done outside of the perl core. The rest should be done outside . (I too want all in the core) I don't know if you noticed the earlier thread, but there's a few people (including myself) who are still having trouble understanding how your proposal works. Could you please provide a brief idiomatic example of some code where this proposal would provide a real practical benefit--enough that slow learners like myself can really understand what it makes easier, and how? It would be great if you could provide the equivalent Perl 5 code too. TIA, Jeremy
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
Nathan Wiger [EMAIL PROTECTED] writes:
Nathan Torkington wrote:
Not every subroutine corresponds to a method call exposing
object-internal data. Most of my subroutines *do* something and make
no sense to be called lvaluably. Explicit marking the compiler pick
up assignments to non-lvaluable subroutines. It makes sense to
explicitly mark the rare cases (:lvalue), rather than the common
(:no_assignment).
Well, this argument makes more sense. However, I still have to disagree.
In fact, I think the opposite: ALL subs *should* be lvaluable by
default. Here's why.
One word: CPAN (ok, an acronym :). Let's take CGI.pm as an example.
Currently, you can do this:
$val = $cgi-param($name);# get the param
$cgi-param($name, $val); # assign a val
So, it seems the next logical extension would be this:
$cgi-param($name) = $val;# assign a val
No problem. In fact, this fits under your rules. HOWEVER, it also
assumes that Lincoln thought that param() was :lvalue-worthy. What if he
forgot? Or didn't think of this case?
Hmm... on a cursory glance at CGI.pm it would appear that just doing
sub param : lvalue {
At the beginning of the param definition will make it Just Work(tm).
And if lvalue access were made the only way of doing assignment of
params in this context then a whole bunch of the code in param could
be removed.
--
Piers
Re: RFC 109 (v1) Less line noise - let's get rid of @%
"J. David Blackstone" [EMAIL PROTECTED] writes: I find the standard prefix symbols so intuitive I find it hard to articulate the reasons why I balk at giving them up. It's like explaining breathing or the ability to distinguish colors. Bravo! What he said! Hear, hear! [FX: Waves order paper in the air] -- Piers
Re: English language basis for throw
[EMAIL PROTECTED] writes: Please take this discussion to the new -errors sublist. Thanks in advance! Exceptions are not necessarily errors. This belongs in perl-language-flow surely? -- Piers
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote: Let's not move backwards and force people to work like machines. Instead, lets force machines to work like us. I dred to think what kind of machine we would make :) Graham.
Re: Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED] whispered:
| No, neither proposal makes sense. Arrays can be stored compactly and
|
| $a[1_000_000_000] = 'oh, really?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Yes, really!' # :P
|
| OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet.
| My point is that arrays *can* be stored compactly, not that they always
| *are*. Another type of array storage is that required for lazily generated
Isn't this just as true, maybe even moreso for hashes? How much storage is
taken up by
$a{1_000_000_000} = "Sparse, without any special code!";
-spp
Re: Language WG report, August 16th 2000
On Wed, 16 Aug 2000, [EMAIL PROTECTED] wrote: The language group has generated the vast majority of the 100+ RFCs in existence, and is suffering under the deluge of 100-200 posts a day. I would prefer this to be down around 50, but no luck yet :-/ Part of the problem seems to be timezone related... the lag time between an RFC being posted, me seeing the thread and realising the need for a sublist, and Ask actually creating that list, means that you get 2-3 days of traffic before it can be moved elsewhere, and a single RFC can easily generate 50 posts. I think that all this... Several sublists have been spawned, but we're not sure how successful they are yet. They seem to have low traffic, which could mean that they simply aren't working (because nobody wants to use them), or that they *are* working (because the people previously discussing the subject on -language weren't deeply interested and just joining in for the hell of it, and the sublists scare off the dilletantes). I think that an NNTP interface would be *seriously* useful to the sublists. ... is the cause for this. All the discussion is taking place in the master list before the sublists are spawned. You can only express the opinion that foo is not bar and never should be so many times. (To be fair, I collapse my lists, and don't pay attention to what is posted to what list.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED]
whispered:
| No, neither proposal makes sense. Arrays can be stored compactly and
|
| $a[1_000_000_000] = 'oh, really?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Yes, really!' # :P
|
| OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute
yet.
| My point is that arrays *can* be stored compactly, not that they always
| *are*. Another type of array storage is that required for lazily
generated
Isn't this just as true, maybe even moreso for hashes? How much storage
is
taken up by
$a{1_000_000_000} = "Sparse, without any special code!";
Yes, in this case (it wasn't my example!). But I would hope that we provide
a way of providing compact array storage where we need it. This would be
useful for lists of floats or ints that will be frequently iterated through
and directly manipulated. Image processing and statistical analysis come to
mind as obvious applications. Anyway, this is hard to discuss without an
RFC... I'm sure I've get some time to write one someone around here...
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
This has already been done for Perl 5.6.1. Here is what perldelta.pod has to say. =head2 Arrays now Always Interpolate Into Double-Quoted Strings In double-quoted strings, arrays now interpolate, no matter what. The behavior in perl 5 was that arrays would interpolate into strings if the array had been mentioned before the string was compiled, and otherwise Perl would raise a fatal compile-time error. In versions 5.000 through 5.003, the error was Literal @example now requires backslash In versions 5.004_01 through 5.6.0, the error was In string, @example now must be written as \@example The idea here was to get people into the habit of writing C"fred\@example.com" when they wanted a literal C@ sign, just as they have always written C"Give me back my \$5" when they wanted a literal C$ sign. Starting with 5.6.1, when Perl now sees an C@ sign in a double-quoted string, it Ialways attempts to interpolate an array, regardless of whether or not the array has been used or declared already. The fatal error has been downgraded to an optional warning: Array @example will be interpolated in string This warns you that C"[EMAIL PROTECTED]" is going to turn into Cfred.com if you don't backslash the C@. See Lhttp://www.plover.com/~mjd/perl/at-error.html for more details about the history here. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Lightning flashed, thunder crashed and Jonathan Scott Duff [EMAIL PROTECTED] whispered: | Um, it's not guaranteed to blow up in 2038. That's an implementation | detail. IF we implement our time values as 64-bit integers (for | instance), we'll long out-live the 2038 deadline. I don't know about anyone else, but I don't intend to care by the time the 2038 deadline comes around. ;-) I hope to still be alive and enjoying my grandchildren by then, but I really hope to not be still programming! -spp
Re: RFC 104 (v1) Backtracking
Johan Vromans wrote: Damian Conway [EMAIL PROTECTED] writes: As I understand things: BLOCK1 andthen BLOCK2 evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2 evaluates to "false", then BLOCK1 is re-evaluated. So how is that different from: do BLOCK1 until do BLOCK2 It's the same. But the real fun starts when blocks and functions can suspend and resume. There's already an RFC for coroutines that proposes allowing suspension and resumption of subroutines. Do the proposed backtracking operators buy anything that do/until/coroutines don't provide?
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
On Wed, Aug 16, 2000 at 12:14:09AM -0700, Nathan Wiger wrote: No problem. In fact, this fits under your rules. HOWEVER, it also assumes that Lincoln thought that param() was :lvalue-worthy. What if he forgot? Or didn't think of this case? Then you email him with a patch, and your reasons why your lvalue patch should be applied. If he likes it, it's included otherwise it's not. Don't second-guess the design decisions of module authors who may have perfectly good reasons for doing things the way they do. Worse, what if a somewhat novice writes a module and doesn't know about :lvalue, or at least not how to use it. But an experienced user picks up their module DoCoolStuff.pm on CPAN and tries it: Then that experienced user can patch the code and send email to the novice explaining lvalue subs and why he should use them. Ooops! The author didn't use :lvalue. So even though this makes perfect sense to be able to do, since the author forgot to use :lvalue, you lose a really cool syntactic tool. This seems backwards. Seems right to me. I'd rather assignment to a function work on purpose rather than on accident. If lvalue subs are the default, then they "accidently" work where maybe they shouldn't. Whether a sub should be lvaluable should be a conscious decision made by the subroutine author. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On Wed, Aug 16, 2000 at 09:49:36AM -0400, Stephen P. Potter wrote: Lightning flashed, thunder crashed and Jonathan Scott Duff [EMAIL PROTECTED] whispered: | Um, it's not guaranteed to blow up in 2038. That's an implementation | detail. IF we implement our time values as 64-bit integers (for | instance), we'll long out-live the 2038 deadline. I don't know about anyone else, but I don't intend to care by the time the 2038 deadline comes around. ;-) I hope to still be alive and enjoying my grandchildren by then, but I really hope to not be still programming! That must sound awfully similar to what the COBOL programmers in the 60's said when they figured that two digits is enough :-) -spp -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Aug 15, 3:16pm, Russ Allbery wrote:
Wholeheartedly agreed. If something is an array, it should start with @.
If we're adding language changes that introduce arrays that don't start
with @, that's the mistake.
Agreed, but with a slight change of perspective. I don't think it's
so important that a variable that _holds_ a list be prefixed with a '@'.
What's more important is that when you _use_ a variable, you prefix it with
a '@' to indicate the expected return type. At that point, Perl can DWIM
or FOAD accordingly.
e.g.
$foo = [ 1, 2, 3 ];# it's a list (ref), but starts with a '$'
@bar = @$foo; # but now we "cast" (deref) it to look like a list
The confusion comes (IMHO) in having to add funny characters together,
or doing funky "casting" to make the right kind of value come from the
right kind of variable.
@$foo; # '$foo' is the list, dereferenced to a list '@'
$foo{bar} # '%foo' is the hash, accessed to return a scalar '$'
@foo{bar,baz} # '%foo' is the hash, sliced to return a list '@'
@$foo{bar,baz} # '$foo' is a hashref, sliced to return a list '@'
You get these weird situations where you're accessing a variable as
'@something' but it's actually coming from '%something'. Hence the
Highlander Variables RFC which should hopefully do away with
much of this confusion.
A
--
Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated.
[EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 11:46 PM 8/15/00 -0400, Stephen P. Potter wrote: Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered: | Doesn't it make more sense to get rid of arrays and just use hashes? | | I guess it depends on what you think makes sense; but it seems to me | that an array is a more fundamental data type; that it's easier (i.e. | more efficient) to build associative arrays from arrays, than vice versa. | | It's silly to throw either of them out. Perl might be many things, but a | reductionist language it ain't... Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). It's because they've got so different an implementation, and their performance characteristics are so different. They're also conceptually distinct. While there is a lot of overlap, there's also a rather large area of difference. While you can fake one with the other, it doesn't mean you should. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 104 (v1) Backtracking
"MC" == Mark Cogan [EMAIL PROTECTED] writes: is equivalent to @a = (\$a, \$b, \$c); rather than what you wrote. MC Ah, so it is. I'd argue that that's broken and should be handled with map MC or for. Err, That's not an accident. Larry designed that in. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Default filehandles(was Re: command line option: $|++)
I'm not sure if you are disagreeing with me or not. The context was the statment that $STDOUT is the _default_ filehandle. I was pointing out that by _overriding_ the instantaneous meaning of $STDOUT to the default fail handle, one would lose the immediate access to the previous value. I.e. $STDOUT should always mean one and only one file at a time. Unless one wants to have a $DEFAULT filehandle and get rid of single arg select. chaim "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: JSD On Tue, Aug 15, 2000 at 06:53:30PM -0400, Chaim Frenkel wrote: What if you want to print to a default file handle and also to STDOUT? select(OTHERFH); print "This goest to OTHERFH\n"; print STDOOUT "This went to STDOUT\n"; JSD print $_ "Here I come to save the day!\n" for ($PERL::STDOUT, $myfh); JSD And again, if you want to print different stuff to different JSD filehandles, you know how to use the JSDprint FILEHANDLE LIST; JSD version of print. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Lightning flashed, thunder crashed and Russ Allbery [EMAIL PROTECTED] whispere d: | Arrays are ordered. Hashes are not. Sure, you can iterate over a hash, | but add an element to one and you can change the order of everything in | it. | | Formally, I believe it's permissable for a hash implementation to return a | different order the second time you iterate through it from the first What stops us from imposing order on this chaos? If they are currently defined as not having any specific order, why can't we say they always return in numeric || alphabetic || ASCII || whatever order we want? The internal storage implementation can be kept seperate from the external interface. A hash *should* be able to be advantageous over an array in just about all respects, except maybe size. And, we've shown how a sparse array can be handled in a hash without any special machinations. -spp
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"BB" == Buddha Buck [EMAIL PROTECTED] writes: BB I am assuming that the system clocks are set accurately to UTC (or some BB derivative, like (US) Eastern Standard Time). UTC is what time-servers BB report. UTC has leap seconds, which are inserted (or, theoretically, BB deleted) at the end of December 31st and June 30th, as needed. Oh, I was under the impression that they only occur at Dec 31. BB This means that 86400 seconds (one day) after 2000 Dec 31, 12:00:00 UTC BB is not necessarily 2001 Jan 1, 12:00:00 -- it could be 11:59:59 or BB 12:00:01 as well. And there is no way to know that ahead of time. Hmm, there are negative leap seconds? BB If we have to pick and epoch in an OS-neutral way, I think I for one BB would be happy with something like this in the docs for the time BB functions: BB BB All date and time functions, unless otherwise documented, assume the BB use of the International Atomic Time (TAI) timescale. TAI differs from BB standard time (UTC) in that TAI does not have "leapseconds". BB It is likely that the OS clock was set to UTC, not TAI. This slight BB difference (22 seconds as of 2000) should not cause any problems unless BB date computations of over 6-months with second accuracy are needed. BB time() returns the number of seconds elapsed since the beginning of the BB International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958. BB date($) returns a year-month-day-hour-minute-second representation of BB the time passed to it (in seconds since the TAI epoch). The BB representation assumes the TAI timescale. BB - So if I understand you, the instantaneous time is correct. But calculating backwards to what the instantaneous time would have been, or calculating what the instanataneous time will be will not work. But your blurb would be a lie. How would one ensure the correct difference to the TAI? And what would be the translation to the system time? What do we do with stat(), utime(), sleep(), select(), events, etc. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Nathan Wiger wrote:
Ok, here goes. First off, I *did* read the RFC. I never respond before
Thanks, this response is more like it.
reading. Personally, I wish people would quit coming up with these silly
"let's drop the prefixes" RFC's that everyone on this list is completely
familiar with.
Well there was the Highlander one but nothing else was obvious. Of course
the RFC list could do with a search engine.
Yeah, and isn't it cool that Perl gives you easy access to using and
understanding such complex data structures:
print @{ $cars-{$model} };
That "junk" makes it easy to see that you're derefencing a hashref that
contains a key which is pointing to an array. How is this:
it's a list of stuff - but a list of WHAT stuff? The @ is essentially
useless.
print cars-model;
any clearer? Nicer to look at? Maybe for some. Not for me, I like the
yep. yep, and easier to teach.
former. Maybe it doesn't let you know exactly what you're getting, but
you're a lot closer. And this:
print "Welcome back, $fullname, to $website!\n";
is MUCH better than this:
print "Welcome back " . fullname . " to " . website . "!\n";
I agree. That's why I believe in retaining the $. The distinction between
variable and non-variable is still useful.
Those days are gone. Perl 5 introduced the idea of Objects
and now any variable can be one of ten million possible
types all of very different behaviours.
Not true!! Only $scalars can hold objects. Now, @arrays and %hashes can
hold groups of objects, but only $scalars can hold objects.
"Groups" is a meaningless concept. You have particular objects which store stuff.
Is an image of a distant galaxy singular (one image) or plural (ten zillion pixels).
My argument, based on my practical experience, is that all the @% are essentially
useless now.
However, if you have object polymorphism, then you don't have this
problem. Objects are automatically converted to numbers and strings
on-demand. The internals people are doing some really interesting stuff
along these lines.
There is already overloaded stringify. Why does RFC49 not discuss this?
To summarize, you should read RFC's 49, 73, 28, and the link to TomC's
email I sent you. These address the real problems, and not the symptoms.
Yes. And I read TomC's stuff on those lines at least 6 years ago. Which
was why I got annoyed.
The point remains - why treat hashes and arrays as special prefix types?
It just confuses the language to have to use $ for one kind of collection
and @ for another.
ok we could use @ for everything - but @ implies 1D ness.
Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Nathan Torkington wrote: * you misunderstand the purpose of $ and @, which is to indicate singular vs plural. You say a $ indicates a string or number, but really it indicates a single thing. Similarly @ isn't just a variable marker, it's used to indicate that you get multiple things: @foo[2..10] @$foo No I completely understand their purpose, I just argue it is no longer useful. * current typing provides rudimentary compile-type checking. Saying: $foo = (1,3,5); gives a warning. Saying: this would create a $foo array %foo = "Nat"; gives a warning. You'd lose that. To get it back you'd need this would give a syntax error! * no sample code. If you're proposing something as big as this, I *really* want to see how it's going to change the language. Take an existing 30 line program that does lots of work with variables and convert it. Show me how it affects things like slices. I want to make sure that code that is currently easy doesn't become hard. good point. what code would you like? don't get mean. :) * you complain that @foo will become more meaningless once we have different data structures that act as collections. You don't consider using @foo for those, though: my @foo : FIFO = (4,5); This fits in with my personal vision of how Perl6 will handle new data types: better support for tie, basically. You can plug in your own C or Perl code to implement new types that masquerade as scalars, arrays, or hashes. Someone else suggested this in the thread, and you treated it as already dealt with in the RFC, but I don't think it's dealt with at all. I can't see how saying my @foo : SOME_TYPE_THAT_IMPLEMENTS_ARRAY_OPERATORS = (4,5); is going to debase the meaning of '@'. "Groups" is a meaningless concept. You have particular objects which store stuff. Is an image of a distant galaxy singular (one image) or plural (ten zillion pixels). My argument, based on my practical experience, is that all the @% are essentially useless now. Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Damien Neil wrote: On Tue, Aug 15, 2000 at 05:45:04PM -0400, Karl Glazebrook wrote: I hope people will actually read the RFC before coming back with these canned responses which I (and presumably everyone else on this list) am completely familiar with. I used to believe that too! Honest... I think you do a significant disservice to brush off criticism so blithely. Complaining that anyone who disagrees with you has not read the RFC is unlikely to garner much support. It was the response which was blithe, it just re-iterated arguments we are all completely familar with and did not address my point in the RFC. Line noise or not, I like the type prefixes. Great. I don't like them. snrub($a); snrub(@a); snrub(%a); snrub(@$a) snrub(%$a) Each one of these does something different. I know, just by looking at the expression, with absolutely no further knowledge of what the function and variable involved are, the general nature of what is going on. I know whether the function is receiving one argument or several. I can make reasonable assumptions about what will happen to the contents of the variable. I know something about what operations I can perform on the variable. and this is supposed to be good? presumably snrub() has a first line like my($apples, $oranges, $price)=@_ and it would be far clearer to call it that way. Perhaps we should remove context? Sure, you won't be able to test for @a == 5 any more, but we can just rewrite that as $a-length == 5. At this point, there isn't much need for the $, though, so we can just say a-length == 5. That - is ugly, though; maybe we can turn it into a . like the rest of the world, at which point we're every bit as good as Python! Y'know, I like Python. Lot of nice things in that language. Maybe we should all jump over to their mailing lists rather than wasting our time with Perl 6. Python is really nice and we should endeavour to learn why a lot of people like it so much rather than telling them 'good riddance'. Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
"J. David Blackstone" wrote: =head1 TITLE Less line noise - let's get rid of @% I understand that with the pervasiveness of object-orientation we are now more than ever seeing objects that behave like arrays and hashes and that it seems strange to see these listlike or hashlike objects represented as scalars. However, this is what the tie interface was designed for. If your object works like an array or a hash, by all means, provide the ability to tie it to an array or a hash. The tie(0 interface is not very useful for multidim arrays, you have to say $x[42][44][49] and do multiple levels of tieing whereas one just desires to say $x[42,44,49] Having once lived in darkness before the marvels of OO enlightened me (meaning I used to just think object-oriented was a useless buzzword), I am still very sympathetic towards allowing people to come to Perl without any requirement that they learn OO. While this proposal certainly does not require OO, it seems to be assuming the universal use of it. I like that too. I find the standard prefix symbols so intuitive I find it hard to articulate the reasons why I balk at giving them up. It's like explaining breathing or the ability to distinguish colors. I strongly disagree with the assertion that the Perl type prefixes are line noise. I think that phrase is very emotionally charged but carries little objective fact, and I think you would do better to come up with a different title. Just my humour. You should have seen the draft. Don't get too emotional - I don't expect to win. I noticed that the examples you cited in a later example about "cluttered" code all seemed to include references. May I suggest that perhaps you would be happy if there were just a cleaner syntax for dealing with references? Perhaps. Karl
Re: RFC 82 (listops in list context)
(Not feasible yet, but...) Would Unicode reduce the problem? Take some operators from the math symbols and make them the matrix op versions? Then the 'ascii' versions would remain the scalar ops. I can see that this would give problems for current editors and displays, but by the time perl6 comes out, perhaps the situation would be better. (Now, if we add all that APL symbols ...) Thoughts? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 91 (v1) Builtin: partition
Lightning flashed, thunder crashed and Perl6 RFC Librarian [EMAIL PROTECTED] whispered: | =head1 TITLE | | Builtin: partition | | =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. This is very similar to what unzip does. Would it be better to combine them into a single function that could do both operations (and possibly others) with a flag? In fact, couldn't all this (zip, unzip, partition) be handled as part of pack and unpack? -spp
Re: RFC 104 (v1) Backtracking
Damian Conway wrote:
So how is that different from:
do BLOCK1 until do BLOCK2
???
Because if BLOCK1 ever evaluates to False, the operation terminates.
It's more like
do { r = f1() } until ( not r or f2() );
--
John Porter
Re: RFC 58 (v1) Cchomp() changes.
Lightning flashed, thunder crashed and Nathan Wiger [EMAIL PROTECTED] whisper ed: | I suggest a modification to this RFC: if chomp() is called without args, | it modifies $_ directly, consistent with its current implementation. | That way you can write: If it is called without args, it really is just chomp(). It needs to be if it is called in a void context. -spp
Re: RFC 104 (v1) Backtracking
On Wed, Aug 16, 2000 at 07:42:33PM +1000, Jeremy Howard wrote:
raptor wrote:
]- I tried minimalistic approach as small as possible additions to the
Perl
language, we get only the "backtrack" mechanism i.e. something that is
harder or slower to be done outside of the perl core.
The rest should be done outside . (I too want all in the core)
I don't know if you noticed the earlier thread, but there's a few people
(including myself) who are still having trouble understanding how your
proposal works.
Could you please provide a brief idiomatic example of some code where this
proposal would provide a real practical benefit--enough that slow learners
like myself can really understand what it makes easier, and how? It would be
great if you could provide the equivalent Perl 5 code too.
Here's some perl psuedo code that'll implement the "andthen" semantics:
BLOCK1 andthen BLOCK2 andthen BLOCK3 andthen BLOCK4
B1: if (BLOCK1) {
B2: if (BLOCK2) {
B3: if (BLOCK3) {
B4: if (BLOCK4) {
return "true"
} else { goto B3 }
} else { goto B2 }
} else { goto B1 }
}
return "false"
The semantics for "orthen" are similar:
BLOCK1 orthen BLOCK2 orthen BLOCK3 orthen BLOCK4
B1: unless (BLOCK1) {
B2: unless (BLOCK2) {
B3: unless (BLOCK3) {
B4: unless (BLOCK4) {
return "false"
} else { goto B3 }
} else { goto B2 }
} else { goto B1 }
}
return "true"
As for examples where this would be of benefit ... I really can't think
of any.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
(Fwd) Re: RFC 109 (v1) Less line noise - let's get rid of @%
Darn, I sent this to perl6-announce instead of perl6-language. Let's try again. --- Forwarded mail from "Andy Wardley" [EMAIL PROTECTED] I thought very carefully about this before writing the Highlander Variables RFC, and came to the conclusion that it's a bad idea. I've read your proposal, but I'm afraid I still think it's a bad idea. Those funny characters tell the programmer what's going on, and they tell the compiler what the programmer thinks is going on. I'm all in favour of cleaning up some of the syntax and removing some of the ambiguity (hence RFC 9) but I've long since learnt that the funny characters are a strength of Perl, and the concept is sound even if the implementation is a little shaky in places. A -- Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated. [EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: RFC 84 (v1) Replace = (stringifying comma) with =
"Stephen P. Potter" [EMAIL PROTECTED] writes:
Lightning flashed, thunder crashed and Russ Allbery [EMAIL PROTECTED] whispere
d:
| Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
| but add an element to one and you can change the order of everything in
| it.
|
| Formally, I believe it's permissable for a hash implementation to return a
| different order the second time you iterate through it from the first
Actually not. See "perldoc -f values":
] ...The actual random order is
] subject to change in future versions of perl, but it is guaranteed to
] be the same order as either the Ckeys() or Ceach() function would
] produce on the same (unmodified) hash...
What stops us from imposing order on this chaos? If they are currently
defined as not having any specific order, why can't we say they always
return in numeric || alphabetic || ASCII || whatever order we want?
Efficiency. If I just want to map over all elements stored in a hash,
I just want the fastest access to all the elements. If I want to
access the hash by ASCII order of keys, I can `sort keys %hash'.
Think of the keys as being returned in some "efficient" order. The
specific "efficient" order is not specified, but it's guaranteed to be
a fast way to iterate over all keys.
The internal storage implementation can be kept seperate from the external
interface. A hash *should* be able to be advantageous over an array in
just about all respects, except maybe size. And, we've shown how a sparse
array can be handled in a hash without any special machinations.
for (@array) {
# stuff with $_
}
is fast.
for (values %hash) {
# stuff with $_
}
(or the roughly equivalent for loop with `keys %hash' and while loop
with `each %hash') is fast.
for (sort keys %hash) {
# stuff with $hash{$_}
}
is not so fast. So defining a sorted order would negate the advantage
of hashes over arrays you refered to.
It seems like a tied hash would be suitable for what you want. If
ties were efficient, it would be trivial to implement a SortedHash
which would perform "each"-style accesses in sorted order. Standard
Perl library, anyone?
--
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
RFC 58 (v1) Cchomp() changes.
chomp should have options to define what an EOL is. Many times, on Solaris, I could not use chomp because I had to use =~ s/[\n\r ]$// on files that came from NT or even from MS-oriented unix editors.
Re: RFC 110 (v1) counting matches
On Wed, Aug 16, 2000 at 03:04:19PM -, Perl6 RFC Librarian wrote: =head1 ABSTRACT Provide a simple way of giving a count of matches of a pattern. We already have this: $count = () = m/foo/g; =head1 DESCRIPTION m//gt would be defined to do the match, and return the count of matches, this leaves all existing uses consistent and unaffected. /t is suggested for "counT", as /c is already taken. Using /t without /g would be result in only 0 or 1 being returned, which is nearly the existing syntax. Better would be to redefine what m//g means in a scalar context. $_ = "foofoofoofoofoofoofoo"; $count = m/foo/g; 1 is just as true as 7. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 111 (v1) Whitespace and Here Docs
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote: =head1 ABSTRACT With a here doc print ZZZ; the ZZZ has to be at the start of a line and the text of the here doc, is processed verbatum. This results in Here Docs that either stick out in the code, or result in unwanted leading whitespace. There are several FAQs that relate to this problem. This proposal tidies this up. =head1 DESCRIPTION Suggested syntax: print xxx, "xxx", print 'yyy', or print `zzz`. shell does something similar with -xxx; [-] word The shell input is read up to a line that is the same as word, or to an end-of-file. No parameter substitution, command substitution or filename gen eration is performed on word. The resulting docu ment, called a here-document, becomes the standard input. If any character of word is quoted with single or double quotes or a \, no interpretation is placed upon the characters of the document. Otherwise, parameter and command substitution occurs, \ followed by a newline is removed, and \ must be used to quote the characters \, $, `, and the first character of word. If - is used, then all leading tabs are stripped from word and from the document. Graham.
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
At 10:37 AM 8/16/00 -0400, Chaim Frenkel wrote: "BB" == Buddha Buck [EMAIL PROTECTED] writes: BB If we have to pick and epoch in an OS-neutral way, I think I for one BB would be happy with something like this in the docs for the time BB functions: Would you be happy with the following edits? BB BB All date and time functions, unless otherwise documented, assume the BB use of the International Atomic Time (TAI) timescale. TAI differs from BB standard time (UTC) in that TAI does not have "leapseconds". BB It is likely that the OS clock was set to UTC, not TAI. This slight BB difference (22 seconds as of 2000) should not cause any problems unless BB date computations of over 6-months with second accuracy are needed. BB time() returns the number of seconds elapsed since the beginning of the BB International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958. time() assumes that the system clock is set to TAI, and does not correct for accumulated leap-seconds. Arithmetic differences between time stamps made using time() may be off by the number of accumulated leap seconds between the two time stamps. BB date($) returns a year-month-day-hour-minute-second representation of BB the time passed to it (in seconds since the TAI epoch). The BB representation assumes the TAI timescale. BB - So if I understand you, the instantaneous time is correct. But calculating backwards to what the instantaneous time would have been, or calculating what the instanataneous time will be will not work. Exactly. But your blurb would be a lie. How would one ensure the correct difference to the TAI? And what would be the translation to the system time? Unless you want to have to update perl (or a configuration option) every year, it's probably best to not bother correcting for leap seconds. This is essentially what we do now. The major change here would be a change of epoch (to the TAI epoch) and a documentation of the issues involved. What do we do with stat(), utime(), sleep(), select(), events, etc. stat() returns time stamps (made in the past). utime() sets time stamps. They should be compatible with time(). e.g., "utime time,time,@files" should still set the modify and access times of @files to "now". sleep(), select() both take intervals. The time scale is irrelevant. Will events need time stamps, intervals, or other (please specify)? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
On Aug 16, 9:06am, Jonathan Scott Duff wrote:
Passing the lvalue via some other means eliminates this problem. I
forget who suggested it (Buddha Buck?) but
sub foo : lvalue($value) { ... }
That should tie in with function prototypes in general, but I suspect
that the prototype should be on the function name, not on the attribute.
sub foo ($value) : lvalue { }
Thus the prototype covers both cases:
$x-foo($y);
$x-foo = $y;
A
--
Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated.
[EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Nathan Torkington wrote:
Perl makes easy things easy. Hashes are bloody useful, as the last
decade of Perl has borne out. They deserve syntactic support because
they're used a lot and are worthy of a shorthand.
my @aa :assoc;
$aa['foo'] = 'bar';
Is no one getting my point?
The ability of arrays to be indexed by strings, or by any other arbitrary
data type/structure, and, more importantly, for the indexing algo to
be based on a hashing function, or anything else, should be user-
selectable, with certain schemes predefined for your convenience -- the
current hash implementation being the obvious example of that.
I suppose this has more to the with the "Improve Tie" subject, but
what I'm arguing for here is syntactic transparency between regular
arrays and any other kind of arrays (including associative arrays).
Since the range of available syntactic cues -- [] vs {} -- is so limited,
it would be better to have just one, and let the user bind the indexing
scheme to the variable.
--
John Porter
Re: Default filehandles(was Re: command line option: $|++)
Chaim Frenkel wrote: Unless one wants to have a $DEFAULT filehandle and get rid of single arg select. Great minds think alike. :-) I'm in the process of codifying an RFC that will be titled something like: "Replace default filehandle / select with $OUTPUT fileobject" (chose $OUTPUT b/c of $OUTPUT_* variables) Everyone: Let's DROP IT. When the RFC comes out (today), let's pick this back up on -io. Thanks. -Nate P.S. If you're not on -io, this implicitly means you DON'T CARE and are willing to accept whatever we come up with. So, everyone that's interested please get on -io. Thanks again.
Re: RFC 82 (listops in list context)
Chaim Frenkel wrote: Would Unicode reduce the problem? Take some operators from the math symbols and make them the matrix op versions? (Now, if we add all that APL symbols ...) Chaim, I think you are on to something here. But before jumping to Unicode or APL to get more line noise, let's remember something from those early versions of BASIC that supported matrix operations: ... 160 MAT A = B * C 170 MAT PRINT ... The matrix operations were all used following the MAT keyword. Without the MAT keyword, the operators all did scalar stuff. Rather than a "use matrixops" which applies to a whole program or at least a whole module, perhaps we just need to borrow MAT, as in: matrix @a = @b * @c; and even matrix @a = @b || @c; -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 110 (v1) counting matches
On 16 Aug 2000, Perl6 RFC Librarian wrote: Have you ever wanted to count the number of matches of a patten? s///g returns the number of matches it finds. m//g just returns 1 for matching. Counts can be made using s//$/g but this is wastefull, or by putting some counting loop round a m//g. But this all seams rather messy. $count = () = $variable =~ m/foo/g; The () puts the match into list context (so the matches themselves are returned), and that list assignment evaluated in scalar context, giving the number of values assigned to the list. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Jarkko Hietaniemi wrote:
Arrays can be stored compactly and
$a[1_000_000_000] = 'oh, really?' # :-)
But that is far less common than
@a{ 0..100 } = (...);
which, if stored in a hash, would not only be significantly less
efficient than an array, but could generally be expected to elicit
some pathological behavior of the hashing function.
--
John Porter
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
And if lvalue access were made the only way of doing assignment of params in this context then a whole bunch of the code in param could be removed. Maybe this is the confusion. I'm not saying subs should ONLY be lvalue. I think they should be both rvalue and lvalue at the same time. Automatically. Did anybody look at this example? @array = $r-func((split /:/, PASSWD)); # ok @array = ($r-func) = split /:/, PASSWD; # same thing -Nate
Re: English language basis for throw
Peter Scott wrote: At 05:33 PM 8/15/00 -0400, John Porter wrote: The thing I don't like about C++/Java try/catch syntax is the way the blocks are daisychained. That is not intuitive to the flow. I find it quite intuitive :-) I note the smiley. What interpretation should be placed on statements in the try block following a catch block? Whatever you want. I can think of three possibilities. -- John Porter
Re: RFC 110 (v1) counting matches
On Wed, Aug 16, 2000 at 10:20:28AM -0500, Jonathan Scott Duff wrote: m//gt would be defined to do the match, and return the count of matches, this leaves all existing uses consistent and unaffected. /t is suggested for "counT", as /c is already taken. Using /t without /g would be result in only 0 or 1 being returned, which is nearly the existing syntax. Better would be to redefine what m//g means in a scalar context. $_ = "foofoofoofoofoofoofoo"; $count = m/foo/g; 1 is just as true as 7. But you would loose the functionality of \G starting where the last match left off. This is very useful. Graham.
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
On Aug 16, 8:32am, Nathan Wiger wrote: Maybe this is the confusion. I'm not saying subs should ONLY be lvalue. I think they should be both rvalue and lvalue at the same time. Point noted and understood, but I'm with the general consensus here. Lvalue subs should have to be explicitly marked as such. This could, of course, be done automatically for you by a Cuse lvalue pragma, or something similar, but it shouldn't be the default case. A -- Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated. [EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: RFC 110 (v1) counting matches
On Wed, Aug 16, 2000 at 04:41:33PM +0100, Graham Barr wrote: On Wed, Aug 16, 2000 at 10:20:28AM -0500, Jonathan Scott Duff wrote: m//gt would be defined to do the match, and return the count of matches, this leaves all existing uses consistent and unaffected. /t is suggested for "counT", as /c is already taken. Using /t without /g would be result in only 0 or 1 being returned, which is nearly the existing syntax. Better would be to redefine what m//g means in a scalar context. $_ = "foofoofoofoofoofoofoo"; $count = m/foo/g; 1 is just as true as 7. But you would loose the functionality of \G starting where the last match left off. This is very useful. /gg to "count 'em all"? :-) Graham. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
Ooops! The author didn't use :lvalue. So even though this makes perfect sense to be able to do, since the author forgot to use :lvalue, you lose a really cool syntactic tool. This seems backwards. Seems right to me. I'd rather assignment to a function work on purpose rather than on accident. If lvalue subs are the default, then they "accidently" work where maybe they shouldn't. Whether a sub should be lvaluable should be a conscious decision made by the subroutine author. See, I don't see it as that big a deal, especially not if lvalue and rvalue subs work identically. For example, here's code that works identically in Perl: @array = @array, func; # ok push @array, func; # same thing Now, maybe someone would argue one is "more correct" or "better style" than the other. However, TMTOWTDI. That's all lvalue subs are. Remember, just because something's an lvalue DOESN'T mean 2 key things: 1. It's working like a variable 2. It's all the way to the left Please look at this example again: @array = $r-func((split /:/, PASSWD)); # ok @array = ($r-func) = split /:/, PASSWD; # same thing All that is to me is TMTOWTDI. Now, we can argue forever that the second one is a bad STYLE. I would probably agree. HOWEVER, we shouldn't be dictating style to the user, which is all :lvalue does if lvalue and rvalue subs work identically. I'm actually quite surprised that people are disagreeing with me on this one. There's a lot of times when you could use cascading lvalue subs to make things easier: @result = ($first, $second, $r-fix_the_rest) = split /:/, PASSWD; This would be at least 2 lines without a cascading lvalue sub, and less clear: ($first, $second, @rest) = split /:/, PASSWD; @result = ($first, $second, $r-fix_the_rest(@rest)); As an advanced Perl user, I want to be able to exploit such constructs at will. I don't want others deciding programming style for me. -Nate
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 10:27:17AM -0400, Karl Glazebrook wrote:
Nathan Torkington wrote:
* current typing provides rudimentary compile-type checking.
Saying:
$foo = (1,3,5);
gives a warning. Saying:
this would create a $foo array
If () are array constructors, what is the hash constructor?
$array = (1,2,3);
$hash = qw(when Now where Here why Because);# Is it a hash?
Well, now that I've asked the question, I've thought of an answer ...
just use Damian Conway's pair constructor:
$hash = ('when' = 'Now', 'where' = 'Here', 'why' = 'Because');
Hmm. I wonder how you'd pairify a list though? Could that be one of
the unzip() or partition() routines?
Random musings (combining this and John Porter's collapse of arrays
and hashes):
$list = qw(when Now where Here why Because);
while ($list) { $hash[shift $list] = shift $list; }
$odds = map { $_%2 $list[$_] } 0..$#list;
$evens = map { $_%2==0 $list[$_] } 0..$#list;
$hash[$evens] = $odds;
for ($i = 0; $i scalar($list); $i+=2) {
$hash[list[$i]] = $list[$i+1];
}
Gee, I'd hate to lose simple assignment to a hash from a list.
What happens to $_ and @_? How do I get the arguments passed to a
sub?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 104 (v1) Backtracking
Johan Vromans wrote: So how is that different from: do BLOCK1 until do BLOCK2 It's the same. No, not quite. See my other post. -- John Porter
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
On Wed, Aug 16, 2000 at 08:40:18AM -0700, Nathan Wiger wrote: See, I don't see it as that big a deal, especially not if lvalue and rvalue subs work identically. Hrm. Perhaps you aren't explaining yourself clearly. Let's pretend that there is a magical value called $LVALUE that contains the thing being assigned. Are you saying that in somesub = $value; the subroutine Csomesub, being lvaluable by default is free to use or ignore $LVALUE? If so, how does one detect errors? When Csomesub is ignoring $LVALUE the above would silently fail, yes? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 110 (v1) counting matches
On Wed, Aug 16, 2000 at 10:49:16AM -0500, Jarkko Hietaniemi wrote: On Wed, Aug 16, 2000 at 04:41:33PM +0100, Graham Barr wrote: On Wed, Aug 16, 2000 at 10:20:28AM -0500, Jonathan Scott Duff wrote: m//gt would be defined to do the match, and return the count of matches, this leaves all existing uses consistent and unaffected. /t is suggested for "counT", as /c is already taken. Using /t without /g would be result in only 0 or 1 being returned, which is nearly the existing syntax. Better would be to redefine what m//g means in a scalar context. $_ = "foofoofoofoofoofoofoo"; $count = m/foo/g; 1 is just as true as 7. But you would loose the functionality of \G starting where the last match left off. This is very useful. /gg to "count 'em all"? :-) Fine with me. Graham.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
print @{ $cars-{$model} };
print "Welcome back, $fullname, to $website!\n";
O.k., I'm convinced.
Only $scalars can hold objects. Now, @arrays and %hashes can
hold groups of objects, but only $scalars can hold objects.
That's not quite correct. @array or %hash can "hold" an object, via tie.
The real problem is that we lack true object polymorphism. That is,
objects are useless in number and string contexts. This is the problem
that needs to be addressed.
You mean overloading needs to be fixed and finished?
However, if you have object polymorphism, then you don't have this
problem. Objects are automatically converted to numbers and strings
on-demand.
Why should strings and numbers be so special? Shouldn't I want my
object converted to an array or a hash on demand? And if it's context
that drives the conversion, then the following should all be equally
reasonable:
$s = "$obj"; # convert to string
$n = $obj+0; # convert to number
$x = $obj[1]; # convert to array
$x = $obj{y}; # convert to hash
--
John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Damien Neil wrote: I like being able to treat arrays and hashes differently from other things. ... I know, just by looking at the expression, with absolutely no further knowledge of what the function and variable involved are, the general nature of what is going on. I know whether the function is receiving one argument or several. I can make reasonable assumptions about what will happen to the contents of the variable. I know something about what operations I can perform on the variable. Sorry, this is exactly the argument we get from the C/C++/Java heads, who find perl's lack of discrimination between strings and numbers so distasteful. But if we can gloss over the difference between a string and a number, we could (not that we should) also gloss over the difference between an array and an associative array... or between an array and a ref-to-array. Etc, etc. The real problem in the above is context -- when I see @a or %a, I know that it will behave in one fashion in list context, and another in scalar context. $a, on the other hand, may be trusted to remain the same no matter what the context. Indeed, context is everything. There is no reason to expect (or demand) that $ variables are any more or less "trustworthy" than other variables. In fact, with tying, such trust is completely unwarranted. Not to mention overloading. So, using $ and @ to impose context is a reasonable thing to do. Using @ to say "this variable can not be indexed by string" is not. -- John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Russ Allbery wrote:
$args = 'first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ = ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely.
No, it's not. Where are we taught this? It's a myth.
The punctuation imposes context on the variable expression.
$foo[0]
accesses an array. Where's the "@"?
--
John Porter
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 10:38:30AM -0600, John Barnette wrote:
John Porter wrote:
Russ Allbery wrote:
$args = 'first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ = ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely.
No, it's not. Where are we taught this? It's a myth.
The punctuation imposes context on the variable expression.
$foo[0]
accesses an array. Where's the "@"?
It accesses an *element* of the array, which is a scalar. This scalar
might be blessed into a class, or a reference to an array or hash, but
the element itself is still a scalar. Where's the confusion?
I believe Mr. Porter is refuting the claim that "the punctuation is
part of the variable name". As both he and you have demonstrated,
it's not.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Jonathan Scott Duff wrote: Gee, I'd hate to lose simple assignment to a hash from a list. foo %= bar; Hmm, I think I need to write an RFC! -- John Porter
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 11:09 AM 8/16/00 -0400, John Porter wrote: Dan Sugalski wrote: Numbers and strings really aren't different things, at least not as far as people are concerned. They are for machines, but computer languages ultimately aren't for machines, they're for people. I guess I can't fault you for towing the party line on this... Would you stop that? I'm not toeing anything. If I disagreed, believe me you'd hear about it. Strings and numbers are not *exactly* the same, even to humans, are they? At many levels, yes they are. After a point they differ, but what you see written is pretty much treated the same. Most numbers have no solid meaning to people without actual though. IIRC you get zero, one, two, and lots. The difference between numbers and strings is analogous to -- or, on further reflection, IDENTICAL to -- the difference between arrays and associative arrays. (The former are numerically indexed, the latter indexed by strings.) The analogy doesn't hold. And people treat arrays and hashes *very* differently, far more so than the trivial differences in the notation might lead you to believe. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. Now you're appealing to the argument that "if we changed the language to be like that, it simply Wouldn't Be Perl." Not buying it. That's fine, I'm not selling it. It is, nonetheless, rather true. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. I guess I'm not sure what you're getting at here. In the expression Cfoo( bar ), bar is a symbol, regardless of its type. There's no "turning a word into a symbol" going on that I can see. Not symbol to the computer, symbol to the *person*. Human's higher-reasoning capabilities are all symbol based, and a lot of the brain is set to turn external stimuli into symbols to be processed. The visual cortex is good at recognizing things and tagging them with a symbol. When you see a dog, for example, it gets tagged with the symbol for dog. If you're familiar with it, it might get a more specific symbol--a breed, or even an individual. That doesn't happen with words--they're already abstract symbols, though in a different way. Because of that they get recognized at a lower level and passed to the language centers for translation to symbols. That extra handoff and translation takes time and mental effort. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. Yes, they do. People write source. People read source Sure. No argument there. Nonetheless, humans certainly have no instincts, and very likely no inherent capabilities, relevant to computer programming, except for abstract reasoning, which IMHO does not favor one side of this argument over the other. That's an incorrect presumption. Humans have instinct and inherent capabilities for symbol manipulation, language, and pattern matching. That's what's used to write programs and, while it's not ideally suited to the task, it's what we've got. Taking advantage of those human capabilities is one of the things that perl does better than most other languages. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 109 (v1) Less line noise - let's get rid of @%
Karl Glazebrook wrote:
The tie interface is not very useful for multidim arrays, you have
to say
$x[42][44][49]
and do multiple levels of tieing whereas one just desires to say
$x[42,44,49]
But if that is indeed what you desire to say, then there is only
one level, and tie becomes eminently feasible.
sub FETCH {
my( $self, $key ) = @_;
my @indices = split $;, $key;
...
}
(I do something like this in my Tie::Multidim module :-)
--
John Porter
Aus tiefem Traum bin ich erwacht.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 12:44:50PM -0400, John Porter wrote: Jonathan Scott Duff wrote: Gee, I'd hate to lose simple assignment to a hash from a list. foo %= bar; Hmm, I think I need to write an RFC! I'll give you my comments right now ... It seems we are eliminating punctuation to make the language simpler in one respect, yet, because of that, creating new punctuation so that we can use the language in ways we are used to. If that must be the case, then I say, if it ain't broke, don't fix it! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 109 (v1) Less line noise - let's get rid of @%
No, it's not. Where are we taught this? It's a myth. The punctuation imposes context on the variable expression. $foo[0] accesses an array. Where's the "@"? It accesses an *element* of the array, which is a scalar. This scalar might be blessed into a class, or a reference to an array or hash, but the element itself is still a scalar. Where's the confusion? I believe Mr. Porter is refuting the claim that "the punctuation is part of the variable name". As both he and you have demonstrated, it's not. Ah; understood. ~ j.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 10:24:09AM -0400, Karl Glazebrook wrote:
It was the response which was blithe, it just re-iterated arguments we
are all completely familar with and did not address my point in the RFC.
Then perhaps we need to agree to disagree. I feel that a number of
people have addressed your points.
and this is supposed to be good?
presumably snrub() has a first line like my($apples, $oranges, $price)=@_
and it would be far clearer to call it that way.
What makes you presume this? Perhaps snrub() is something like this:
sub snrub {
foreach (@_) {
frobnicate $_;
}
}
You appear to arguing that expressions in function argument lists should
not be evaluated in a list context. Is this really what you mean?
Perhaps we should remove context? Sure, you won't be able to test
for @a == 5 any more, but we can just rewrite that as $a-length == 5.
At this point, there isn't much need for the $, though, so we
can just say a-length == 5. That - is ugly, though; maybe we can
turn it into a . like the rest of the world, at which point we're
every bit as good as Python!
Python is really nice and we should endeavour to learn why a lot of people
like it so much rather than telling them 'good riddance'.
Certainly, we should steal whatever nice features it has that Perl lacks.
Perl should never try to BE Python, though; the world already has Python.
We don't need another Python, we need a better Perl.
One of the fundamental concepts in Perl is context. Would you care to
address the point of what happens to context when you remove @ and %
prefixes?
- Damien
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Wed, Aug 16, 2000 at 12:44:50PM -0400, John Porter wrote: Jonathan Scott Duff wrote: Gee, I'd hate to lose simple assignment to a hash from a list. foo %= bar; No, wait, that obviously leaves the modulus of division scalar foo by scalar bar to foo... No, wait, tha obviously sets the value of lvalue method cal foo to the modulus... No, wait, that applies vectorwise % by the elements of the array bar to all thef elements of the array foo and leaves the moduli in place at foo... No, wait, that's a Ionian columnhead lying in the ground... Hmm, I think I need to write an RFC! I think I need to fork() a few extra copies of myself to keep up with the deluge of RFCs. -- John Porter -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 109 (v1) Less line noise - let's get rid of @%
John Barnette wrote:
John Porter wrote:
The punctuation imposes context on the variable expression.
$foo[0]
accesses an array. Where's the "@"?
It accesses an *element* of the array, which is a scalar.
Still, the "$" does not describe the type of the variable, which
in this case is an array. The "$" imposes scalar context on the
expression "foo[0]". What is in foo[0] is irrelevant.
Where's the confusion?
Right here, apparently. The punctuation (so-called) is NOT descriptive
of the variable's type, despite what some people say.
If it were, then the parser would see "$foo" and immediately conclude
that the variable is a scalar. But no, it has to keep scanning until
it finds other stuff, like {} or [], to decide what type "foo" is.
--
John Porter
