Non-yet-thrown exceptions must be a useful concept.
Non-yet-thrown exceptions must be a useful concept. This is a bullet point from a list in Apo4 introducing coverage of exception handling. Was Larry talking about an exception object that hasn't yet been thrown? Did he refer to this issue again anywhere else in the Apo? --me
Re: 123_456
On Fri, 25 Jan 2002 17:34:12 +, Simon Cozens wrote: Should we be allowed to use _ to group numbers, now that _ is concat? If not _, then what? (if anything?) I don't really understand your question. Currently, . is used for concat and that doesn't inhibit using it in a number, does it? Or what would you suppose that 3.14 means? Quite the countrary: (100 . 000) as a number is indeed 10, as is 100_000. So there's *less* of a conflict than today, in perl5. -- Bart.
Re: What can be hyperoperated?
Larry == Larry Wall [EMAIL PROTECTED] writes:
Larry @result = for @a; @b - $a, $b { $a op $b }
Larry (presuming we make Cfor actually act like Cmap).
Why not just make map do that?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: What can be hyperoperated?
Larry @result = for @a; @b - $a, $b { $a op $b }
Larry (presuming we make Cfor actually act like Cmap).
Why not just make map do that?
The order of Cmap's arguments is wrong. To make the - extraction
syntax work we need the data being iterated to be on the left and the
processor block (actually a closure in Perl 6) to be on the right.
Damian
Barewords and subscripts
A4 said that there were no barewords in Perl 6. Does this mean that
$foo{bar}
actually should be written
%foo{bar}
?
I'm vaguely hoping that the answer is yes, because then we could treat
*all* instances of {...} as a block returning either a closure, a value
for subscripting, or an anonymous hash, rather than having to decide at
tokeniser time.
--
Overall there is a smell of fried onions. (fnord)
Re: Barewords and subscripts
At 05:01 PM 1/26/02 +, Simon Cozens wrote:
A4 said that there were no barewords in Perl 6. Does this mean that
$foo{bar}
actually should be written
%foo{bar}
?
No. That's not a bareword.
I'm vaguely hoping that the answer is yes, because then we could treat
*all* instances of {...} as a block returning either a closure, a value
for subscripting, or an anonymous hash, rather than having to decide at
tokeniser time.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Barewords and subscripts
On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote:
%foo{bar}
It's bare, and it's a word.
I presume you're also happy with these ambiguities:
$foo{shift} vs. $foo{shift}
$foo{bar} vs. sub bar() { ... } $foo{bar}
vs. $foo{+bar}
vs. $foo{bar()}
vs. $foo{+bar}
vs. $foo{bar()}
and they never cause any problems?
Pacific Systems Design Technologies
http://www.perldebugged.com
Although I suppose if we make it harder for people to write buggy
Perl, there's less of a market for debugging books. :)
--
10. The Earth quakes and the heavens rattle; the beasts of nature flock
together and the nations of men flock apart; volcanoes usher up heat
while elsewhere water becomes ice and melts; and then on other days it
just rains. - Prin. Dis.
Re: Apoc4: The loop keyword
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
(Jonathan Scott Duff) wrote:
On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote:
On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote:
What we're cleaning up is the ickiness of having things declared
outside
the braces be lexical to the braces. *That's* hard to explain to
beginners.
But it's handy. And that was, until now, what mattered with Perl.
No, handiness still matters with Perl. It's just that the balance has
tipped a wee bit towards the consistency/regularity/simplicity/whatever
side of the scale.
Besides no one has commented on Steve Fink's (I think it was him) idea
to store the result of the most recently executed conditional in $?. I
kinda like that idea myself. It makes mnemonic sense.
But then I'm sure that someone will come out of the woodwork and say
What about if ((my $a = foo()) ($b 4)) ? or something. To
which I'd say Fooey! I personally don't think that an extra set of
curlies are too high a price for getting rid of weird scoping rules.
But that's just me.
As someone how comes from the C++ world, I'm really glad that C99 saw
sense and added
if (int i = x()) {
// i in scope here
...
}
// i not in scope here
and therefore was really disappointed that Larry wants to take it out of
Perl. The argument about consistency (only variables declared in a block
go out of scope at the end of that block) is valid, but of course Perl6
will not always be following that rule anyway.
The exception is function declarations, named parameters will be declared
outside the statement block that forms the body of the function; yet will
be scoped to that block.
For example, I really don't think that closure and @fileList are expected
to have file scope (for want of a better term), after declaring a function
such as:
sub attempt_closure_after_successful_candidate_file_open
(closure, @fileList) {
#...
}
(From about half way through Apoc4).
If we already have one case where the rule is actually only variables
declared in a block or in its 'controlling statement' go out of scope at
the end of that block, so why not make that the general rule and allow
code such as
while (defined(my $line = $file.readline())) {
# ...
}
not to interfere with code elsewhere in the block that may use a variable
called $line (it certainly makes maintenance easier to add a variable with
out extraneous braces but to have a tightly contained scope).
--
[EMAIL PROTECTED]
Re: Apoc4: The loop keyword
On Fri, Jan 25, 2002 at 12:50:51PM -0800, Erik Steven Harrison wrote:
Besides no one has commented on Steve Fink's (I think it was him) idea
to store the result of the most recently executed conditional in $?. I
kinda like that idea myself. It makes mnemonic sense.
H . . . I could grow used to that. A couple of thoughts.
1) It doesn't seem to buy us much that $_ doesn't already, except some slight
legibility in that we can say what the variable holds as in:
foreach $PIN_number (@list) {
my $PIN = $PIN_number;
#Stuff
}
ENOCONDITIONAL
$? would be set to the result of the most recently evaluated
conditional (things like if(), elsif(), while(), or until())
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: What can be hyperoperated?
On Fri, Jan 25, 2002 at 06:03:55PM -0800, Larry Wall wrote:
Do they need to? In the simple case, the hyperoperator provides list
context to its arguments, but just calls the scalar operation repeatedly
to fake up the list operation. Any operator
@result = @a ^op @b
is really just something like
@result = for @a; @b - $a, $b { $a op $b }
Just to make sure I'm not confused, the for loop above should really
look like this:
@result = for @a; @b - $a; $b { $a op $b }
right? I re-read the Apocalypse and it says that both of these would
be the same, but if that's the case, then I don't understand how you
would take items two at a time across multiple streams.
I expect @a;@b-$a;$b to assign @a[0] to $a, @b[0] to $b, etc.
and @a;@b-$a,$b to assign @a[0] to $a, @a[1] to $b, etc,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Barewords and subscripts
At 05:43 PM 1/26/02 +, Simon Cozens wrote:
On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote:
%foo{bar}
It's bare, and it's a word.
Maybe you want to come up with another term to describe it then... but it
isn't a bareword in Perl. Camel III p.64 footnote: ... It's only a
bareword when the parser has no clue. p.65: If you say Cuse strict
'subs'; then any bareword will produce a compile-time error.
I presume you're also happy with these ambiguities:
$foo{shift} vs. $foo{shift}
I'm not arguing with the ambiguities you pointed out (which have vexed me
on occasion also); just that it ain't a bareword. Unquoted identifier used
as hash subscript is a bit of a mouthful, though.
Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
won't be because of the no barewords rule. If there were such a rule, I
presume you'd also apply it to the LHS of =?
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Barewords and subscripts
Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
won't be because of the no barewords rule. If there were such a rule, I
presume you'd also apply it to the LHS of =?
There is another way to resolve the ambiguity of foo meaning either
foo or foo() depending on current subroutine visibility. This
would also extend then to issue of $hash{foo} meaning either
$hash{foo()} or $hash{foo}. Just use parens.
Oh, I know, I know. I can already hear the mass reaction now: Oh,
horrors! cry the masses from every timezone. But let's think about
it anyway.
Perl's historical optionality of explicit parentheses to delimit a
function's argument list is, like its similar optionality of explicit
quotation marks, a source of ambiguity. And while ambiguity can
be a source flexibility, expressibility, and convenience, it can
also have a darker side that would be better relegated to obfuscated
programming contests than to production-calibre code.
In my experience, many programmers would prefer that all functions
(perhaps restricted to only those of no arguments to appease
hysterical cetaceans?) mandatorily take (even empty) parens. Thus,
shift() in lieu of shift, no matter whether it's as a hash subscript
or the left-hand operand of the comma arrow, or whether it's floating
around free, outside of any such autoquoting construct.
Since this matter has now been mentioned, I would like to suggest that
there lurk other related and perhaps even more important ramifications to
the current optionality of parentheses than the one concerning strings.
Witness:
% perl -MO=Deparse,-p -e 'push @foo, reverse +1, -2'
push(@foo, reverse(1, -2));
% perl -MO=Deparse,-p -e 'push @foo, rand +1, -2'
push(@foo, rand(1), -2);
% perl -MO=Deparse,-p -e 'push @foo, time +1, -2'
push(@foo, (time + 1), -2);
[ Gr. That should read time(). ]
% perl -MO=Deparse,-p -e 'push @foo, fred +1, -2'
push(@foo, ('fred' + 1), -2);
Do you see what I'm talking about? The reader unfamiliar with the
particular context coercion templates of the functions used in code
like
use SpangleFrob;
frob @foo, spangle +1, -2;
can have no earthly idea how that will even *parse*. This situation
seems at best, unfortunate.
I'm sure that if it were somehow possible to require proper placement of all
those parens, even with something like the hypothetical and wholly optional
use strict 'parens', that this would raise the hackles of many a current
Perl programmer. But perhaps this owes more to the fact that those folks
do not have to explain or justify this particular--well, let's be charitable
and merely call it an issue--to those whom it befuddles or annoys than it
owes to any legitimate convenience or desirable functionality. When you get
to see non-wizards repeatedly stumble on these ambiguities on a regular basis,
this whole situation can quickly become a source of frustration, embarrassment,
or both. Whether this scenario inspires apologetics or apoplectics is not
consistently predictable.
However, if one were simply *able* to write something like
use SpangleFrob;
use strict 'parens'; # subsumed within a blanket use strict
frob(@foo, spangle(1, -2));
frob(@foo, spangle(1), -2);
frob(@foo, spangle() + 1, -2);
then, without even inflicting grievous harm on compile-time checking of
arguments, one could at least always readily discern which arguments went
where--which hardly seems an undesirable goal, now does it?
Nevertheless, even that wouldn't help in being able to know whether
that's really meaning
frob(@foo,
frob( \@foo,
frob( scalar @foo,
It all would depend upon the existence of coercion templates such
as frob(@...), frob(\@...), and frob($...). Sadly, there's no
B::Deparse switch to tell you under which scenario your operating,
but that's all probably best left for a semi-separate discussion
(if at all).
The devil's advocate might suggest that not knowing which of the
three treatments of @foo silently occurred in the frobbing function
call--which they with some credibility assert a desirable goal--goes
hand in glove with not knowing whether spangle is here acting as a
list-op, as a un(ary)-op, or as a non(e)-op. But considering that
such devils need no help in their advocacy, I shan't bother to do
so myself. :-)
--tom
Re: What can be hyperoperated?
Damian Conway writes:
: Larry @result = for @a; @b - $a, $b { $a op $b }
:
: Larry (presuming we make Cfor actually act like Cmap).
:
: Why not just make map do that?
:
: The order of Cmap's arguments is wrong. To make the - extraction
: syntax work we need the data being iterated to be on the left and the
: processor block (actually a closure in Perl 6) to be on the right.
Well, that's not insurmountable, but it would require parens if we
stuck with the semicolon notation. This would find an end of statement
too soon, after the @a:
@result = map - $a; $b { $a op $b } @a; @b;
so it'd probably have to be written as one of
@result = map - $a; $b { $a op $b }, (@a; @b);
@result = map (- $a; $b { $a op $b }, @a; @b);
@result = (map - $a; $b { $a op $b }, @a; @b);
(@result = map - $a; $b { $a op $b }, @a; @b);
That's starting to get up there on the grottiness meter. Since semicolon
is probably just separating lists within lists, perhaps
@result = map - $a; $b { $a op $b }, [@a], [@b];
is a valid alternative. But it's still not as comely as the Cfor,
which never needs the parens, since it knows the {} is coming.
Perhaps we shouldn't be using ; for this.
Larry
Re: What can be hyperoperated?
Larry pondered: Perhaps we shouldn't be using ; for this. That has occurred to me on several occasions but, checking my pockets, I find I'm fresh out of spare symbols to replace it with. We could always use colon, of course ;-) Damian
Re: Non-yet-thrown exceptions must be a useful concept.
Me writes: : Non-yet-thrown exceptions must be a useful concept. : : This is a bullet point from a list in Apo4 introducing : coverage of exception handling. Was Larry talking : about an exception object that hasn't yet been thrown? : Did he refer to this issue again anywhere else in the Apo? Yep. The current unthrown exception is put into $!, and that's the exception that Cor die defaults to throwing. Larry
Re: What can be hyperoperated?
[EMAIL PROTECTED] writes:
: Larry pondered:
:
: Perhaps we shouldn't be using ; for this.
:
: That has occurred to me on several occasions but, checking my pockets, I
: find I'm fresh out of spare symbols to replace it with.
:
: We could always use colon, of course ;-)
Well, more likely than that would be double colon. It would stand out
better:
for @a :: @b :: @c - $a :: $b :: $c { ... }
And it would probably not interfere much with the doubledoubledots
of the ??:: operator. (Certainly less than the ; overloading.)
On the other hand, semicolon works out really nicely within brackets
for multidimensional slices, and the mathematicians like it. And I
don't know how the :: would fit in with other adverbial generalities.
Larry
Re: What can be hyperoperated?
On Sat, Jan 26, 2002 at 04:52:53PM -0800, Larry Wall wrote:
@result = map - $a; $b { $a op $b } @a; @b;
Something seems wrong with this, but I can't quite put my finger
on what it is. I think it's the - directly after map - - looks
too much like an operator. And even if you read - as the natural
to, you get map to $a and $b, perform $a op $b, for @a and @b
I'd be happier with
map @a; @b - $a; $b { $a op $b }
(Map elements of @a and @b to $a and $b, and do '$a op $b') but
the semicolons seem blecherous there. But this is starting to look
more like ML than Perl.
That's starting to get up there on the grottiness meter. Since semicolon
is probably just separating lists within lists, perhaps
@result = map - $a; $b { $a op $b }, [@a], [@b];
But (@a; @b) *is* a list of two lists, so you'd want to keep that.
is a valid alternative. But it's still not as comely as the Cfor,
which never needs the parens, since it knows the {} is coming.
Perhaps we shouldn't be using ; for this.
Given hyperoperators, I wonder if we can actually drop map.
--
Calm down, it's *only* ones and zeroes.
Re: What can be hyperoperated?
Simon wrote:
Given hyperoperators, I wonder if we can actually drop map.
So:
@result = map { block } @data;
becomes:
@result = {block}^.(@data);
Hmmm.
Damian
Re: What can be hyperoperated?
On the other hand, semicolon works out really nicely within brackets for multidimensional slices, and the mathematicians like it. And I don't know how the :: would fit in with other adverbial generalities. Yes, I think semicolon is the correct solution. We just have to explain that it's only allowed to be a naked singularity within a Cfor. Elsewhere it has to be decently shielded by the statement event horizon of a pair of brackets. ;-) Damian
