use fatal err fail
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that "use fatal" be on by default,
and
that "err" be turned into syntactic sugar for a very small try/CATCH block.
Basically, my observation is that no-one consistently checks the return values
of
the built-in functions. As Mama[1] can attest, lots and lots of code is posted
to
Perl Monks calling open without checking the return value. Even among those who
check the return value of open, just about none check for close[2]. And have
you
*ever* seen a program that actually checks the return value of print[3]?
Exception handling seems to provide a good solution to this. Instead of writing
"open ... or die ..." every time, we can just blindly assume the open worked,
and
catch the error later. If we don't catch it, it does exactly what the "die"
would
have anyway, so we're no worse off. The exception propagates upwards until it's
handled, or it terminates the program. At least the program doesn't continue
blindly, believing all to be well. The problem with typical exception handling
code is that it quickly becomes bulky and ugly. Compare.
#ignore any files we don't have access to
for @files {
my $fh = open $_ or next;
load_config_from($fh);
}
with
#ignore any files we don't have access to
for @files {
my $fh;
try {
$fh = open $_;
CATCH {
next;
}
}
load_config_from($fh);
}
So returning a special value makes checking the return code simpler, but hurts
us
if we forget. Throwing an exception saves us from forgetting, but has the
nastiness of catching that exception.
I propose that the spelled out version of // be renamed to something like "dor".
(I'm willing to accept other suggestions on that.) "err" becomes a
single-expression level try/CATCH block. The left hand side is executed, and
if it
successfully returns anything (even undef), it's value is used. If it throws an
exception, however, that exception is caught and the right hand side is
evaluated
and used. So that code becomes
for @files {
my $fh = open $_ err next;
load_config_from($fh);
}
which is just syntactic sugar for
for @files {
my $fh = try {
open $_;
CATCH {
next;
}
}
}
"err" would bind tighter than assignment, so it can be used to provide a
fall-back
value to use in case the normal flow of control fails. Using "no fatal" is
still
allowed, but you can achieve almost the same thing [4] by adding "err $! but
undef"
after calls whose failure you want to handle that way.
I think on the whole this gives us a way to allow exceptions to be used
everywhere,
while making it clean and simple enough that it doesn't bog us down too much.
[1] http://www.perl.com/pub/a/2005/09/22/onion.html?page=6
[2] I've actually seen data lost due to this. When drive space is very limited
(due to, for instance, a user quota) it's often possible to open a new file
(since
there's some space left), but the close fails since too much was written to it.
[3] Actually, I'm not sure this is fair. It seems that, due to buffering and
other
things, print returns true even when it doesn't actually succeed. But why let
facts get in the way of rhetoric?
[4] The difference is that "no fatal" would only affect code that calls "fail"
itself. The "err" would affect code that directly calls "die", too.
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Eschew obfuscation!
Re: What Requires Core Support (app packaging)Z
On Sat, 18 Sep 2004, Jonadab the Unsightly One wrote: > James Mastros <[EMAIL PROTECTED]> writes: > > >As a special case, if the "filename" argument to perl is a > >directory, and the directory contains a file named "main.pl", > >then the directory is prepended to @*INC, and main.pl is run. > > I think it would be useful if the "directory" could also be an archive > in certain common and widely-supported formats (gzipped tarball and > PKWare ZIP being the most important ones to support IMO; probably > should go for bzip2ed tarball also and maybe disk images containing > ISO filesystems if a suitably unencumbered extant code library can be > found for reading them). The question is whether any of that needs to be core, and I'm starting to strongly think it doesn't. I was about to say that perl should only go trying to figure out that the file is an archive if you pass it an appropriate command-line argument, but then I realized that argument could well be -MPAR (or such). Then the module would have to do some magic to see how it's being called and analyze the parameters, look for archives, etc, but the perl executable itself wouldn't need anything special (which feels a lot nicer, since presumably updating the PAR module installed would be a lot easier than updating perl to support a new archive type). -MPAR could also handle the directory case, removing any special casing whatsoever from perl. -- Adam Lopresto http://cec.wustl.edu/~adam/ "Just once, I wish we would encounter an alien menace that wasn't immune to bullets." --The Brigadier, "Dr. Who"
Re: The first shall be first (was "Re: parameter contexts (was: Synopsis 9 draft 1)")
On Sat, 4 Sep 2004, David Green wrote: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Larry Wall) wrote: > >I'm still thinking A is the first one and Z is the last one. Someone > >talk me out of it quick. > > The actual issue is how to distinguish cardinal numbers from ordinals, > right? So if we want ordinal numbers, why not use ordinals? > > say "From the home office in Moose Jaw, Saskatchewan:"; > say @top_AZ_alternatives[1st .. 10th]; > > So the first element is 1st (or 1th), and the last is -1st. Or maybe 0th > is the first? No, that's silly, 1st should be first. 0th could be the > element before the first, and I suppose -0th means after the last. (If > you read from the 0th/-0th element of an array you presumably get undef, > and you could write to it to unshift/push.) Very close. I really like counting from the front using a postfix operator "th" (you'd also want "st" and "nd" to be synonymous, and maybe a special "first") but it seems to me trying to count backwards in that scheme just doesn't quite work. That last element isn't "-1st", that's (or at least "(-1)st", depending on precedence) the one before the 0th, which is the one before the 1st. If you want to count from the end, why not go all the way and use "last", "last-1", "last-2", etc. "last+1" would be the first element past the current bounds, so "push @foo, $bar" would be the same as "@foo[last+1]=$bar". Of course, getting any of this to actually work seems tricky, but doesn't seem any harder than A or Z, and would read extremely well. > We already have ordinals for grammars, so I'm sure we could make 'em work > here. (Maybe "nth()" is an operator that constructs ordinal-objects? > (I kind of want a "th" suffix operator so I can do ($n)th. Although that > doesn't really lend itself to counting from the end, like the supposed > "-nth" operator, unless you can do something like "($n)th but backwards" > ... eh, which may not be worth it.)) I don't see any reason why "st", "nd", and "th" couldn't be postfix operators instead of prefix. -- Adam Lopresto http://cec.wustl.edu/~adam/ "The prince wants your daughter for his wife." "Well, tell him his wife can't have her." - Blackadder III
Re: Return with no expression
On Tue, 24 Aug 2004, Aaron Sherman wrote:
> On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
>
> > You're assuming that C in a ternary operator. It
> > could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
> > that interpretation, one might choose a different name (e.g. C).
> > We could actually define ?? as a binary operator in much the same way.
>
> Yep, and since ~~ auto-topicalizes its lhs for its rhs, your binary ??
> is all you need. I wish I'd seen your message before I sent my recent
> one, as I would have just started from there.
>
> Precedence worries me a bit, since I don't know how ~~ and ?? would fit,
> but it's certainly nice to have this construct use a generic Perl 6
> operator like ~~ and not have to have any ternary constructs in the
> language.
My problem is that then you can't get to the original topic. I think too much
topic-clobbering will be confusing.
say chars($_) > 70 ~~ abbreviate($_) ?? $_; #oops, prints the length
--
Adam Lopresto
http://cec.wustl.edu/~adam/
[MacGyver] is the Martha Stewart of action.
--Patrick J. Mooney
Re: "<->" as "->" with automatic "is rw"
On Fri, 20 Aug 2004, Larry Wall wrote:
> On Fri, Aug 20, 2004 at 10:07:02PM +0200, Juerd wrote:
> : I'm proposing
> :
> : for zip(@foos, @bars, @xyzzies) <-> $foo, $bar, $xyzzy { ... }
> : for %quux.kv <-> $key, $value { ... }
>
> That'd probably work on the keys only if the hash was declared to have
> object keys. At least in Perl 5, the key is always a copy.
>
> : to mean
> :
> : for zip(@foos, @bars, @xyzzies) -> $foo is rw, $bar is rw, $xyzzy is rw { ... }
> : for %quux.kv -> $key is rw, $value is rw { ... }
> :
> : Comments, anyone?
>
> It's really sick, and cute, and I love it. Unfortunately I'm not sure
> it passes the "Are there already too many ways to declare a sub?" test...
>
> It's vaguely possible I could be persuaded on the basis that
>
> for zip @a ¥ @b <-> { ($^a,$^b) = ($^b,$^a) }
>
> could be made to work. But I'm still dubious. And arguably -> {...}
> means the same as sub () {...}, implying there are no arguments.
Arguably it already means that. But if <-> were added, it might be a good
reason to make -> {...} mean -> $_ {...}, using <-> {...} for -> $_ is rw
{...}. A good way to remove one more special case (maybe offsetting the extra
way to declare a sub, and sweeten the whole deal).
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Yesterday upon the stair
I met a man who wasn't there.
He wasn't there again today --
I think he's from the CIA.
Re: Synopsis 2 draft 1 -- each and every
On Fri, 20 Aug 2004, Dan Hursh wrote:
> Peter Behroozi wrote:
>
> > I'm not particular to any of the verbs used yet, but maybe that's
> > because I don't think of the <> as a general iterator, but more of a
> > gobbler-type creature (and formerly a globber, too). Could we try:
> >
> > for $foo.fetch { ... } #or
> > for $foo.grab { ... } #or
> > for $foo.eat { ... }
> >
> > And to replace $/ we could have something like:
> >
> > for $foo.fetch :upto(",") { ... } #or
> > for $foo.fetch :until(",") { ... }
>
> general impose scalar impose list
> --- --
>D $foo.eat$foo.bite $foo.gobble
>N $foo.look $foo.peek $foo.peruse
>
> hmm, I don't like eat in this case
>
>D $foo.take $foo.grab $foo.horde
D $foo.drink $foo.sip$foo.slurp
N $foo.taste
Ok, I'll stop now. But I do sort of (very minorly) like sip as a mini-slurp.
>
> That assumes folks think of grab as being singular and take as being
> open ended. That, and I don't want take to colide with gather{take}.
> Oh well.
>
> Dan
>
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Keyboard not found. Think F1 to continue.
Re: :)
On Thu, 22 Jul 2004, Michele Dondi wrote: > On Thu, 22 Jul 2004, Robin Berjon wrote: > > > >>>Do we have a :) operator yet? > [snip] > > We could mimick XQuery where it is the comment terminator. > > Well, since it's *optimistically* smiling, it could turn off warnings for > the statement it refers to. Obviously, it's very confident about that code, so it should turn on a maximum level of warnings for that statement (assured that it will pass). The modifier to turn off warnings on a line would be ;), winking at us to let us know it's up to something. -- Adam Lopresto http://cec.wustl.edu/~adam/ Eschew obfuscation!
Re: Apocalypse 6: IDs of subroutine wrappers should be objects
On Tue, 8 Jun 2004, Matthew Walton wrote:
> Ingo Blechschmidt wrote:
>
> > One should be able to unwrap $subref using
> > $id.unwrap();
>
> Something tells me that you shouldn't be able to do that. Wrapping is an
> operation on the subref, which implies very strongly to me that
> unwrapping should also be an action on the subref.
>
> > Or, given $id, it'd be cool if you could get the original $subref:
> > my $origsubref = $id.sub();
> >
> > Additionally, $id could coerce to an ID number in numeric context, so
> > $subref.unwrap($id);
> > would still be valid code (==> TIMTOWTDI).
>
> At the very least you'd have to be able to do that as well, I get this
> uneasy feeling about having to do $id.unwrap();. unwrap would be the
> wrong method anyway - it implies unwrapping $id itself, which seems
> wrong because $id isn't wrapped, it's wrapped around something else.
> Maybe $id.remove() or $id.tear_off() or $child.give_present($id), which
> would cause unwrapping to happen very, very quickly and messily.
I agree that unwrap is the wrong name for that. Personally, I'd much rather
have a more generic name, like undo, and have more than just wrappers use it.
Consider (highly speculative):
sub big_long_and_nasty (...) {
my @consequences;
LEAVE {
@consequences ». undo();
}
...
unshift @consequences, $subjref.wrap({...}) // die $horribly;
...
}
Where we can add to @consequences anything else that we'll need to undo to
clean up on our way out. Maybe not that important, since I think the current
thinking is
my $id = $subref.wrap({...}) is leave {.undo()};
which might be even handier (though I think that would unwrap it as it falls
out of that scope, instead of at the end of the subroutine, making it hard to
deal with many nested blocks if you want to revert everything at the end of the
whole sub).
> On the other hand, what happens when you call $id.unwrap() (or
> $subref.unwrap($id)) if $id is an object? What happens to $id? Does it
> turn into some kind of limbo object? Does it become undefined? Is it
> right for $subref.unwrap($id) to be able to do that to $id? Is it right
> for $id to be able to do it to itself?
>
> Hmm. Not a very useful email really. Oh well. It's too hot to think
> straight.
Same here.
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Her hair glistened in the rain like nose hair after a sneeze.
(Chuck Smith, Woodbridge)
but true
I've been trying to follow the recent discussion on roles and properties and
traits and such, but there's something that bugs me. If I understand
correctly, adding a role at runtime using but won't override any methods
defined by the class itself (but it will override inherited methods). But then
if I create a class that has its own method of saying whether it's true or not,
does that mean that "but true" and "but false" won't do anything to it?
class Complex {
has $.real;
has $.imag;
...
#Actually, how do we define this?
method asBoolean(Complex $self:){
return $self.real || $self.imag;
}
...
then somewhere in a function
return Complex::new(0,0) but true;
Since Complex already has an implementation of whatever method decides whether
it's true or not, wouldn't just applying a property be insufficient to override
that?
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Where now the horse and the rider? Where is the horn that was blowing?
Where is the helm and the hauberk, and the bright hair flowing?
Where is the hand on the harpstring, and the red fire glowing?
Where is the spring and the harvest and the tall corn growing?
They have passed like rain on the mountain, like a wind in the meadow;
The days have gone down in the West behind the hills into shadow.
Who shall gather the smoke of the dead wood burning,
Or behold the flowing years from the Sea returning?
Re: The Block Returns
On Fri, 3 Oct 2003, Simon Cozens wrote: > Dunno what .= would mean now . is method call. I'm sure someone will make it > mean something. :) I've been saying for some time now that .= should mean exactly what one would expect it to mean, method call and assign the result, for code like $str .= lc; $linkedlist .= next; $structure .= clone(deep => 1); and such things. Really, making it mean anything else (including nothing at all) would be counterintuitive. -- Adam Lopresto http://cec.wustl.edu/~adam/ perl -le '$_=(split q,",,`$^Xdoc -q japh`)[1].".";y/pj/PJ/;print'
Patterns and junctions
I've had an idea brewing for a while, and since talk seems to have turned to reg^H^H^Hpatterns and rules again, I figured this might be the time to mention it. A while ago someone asked about whether backtracking semantics are mandatory in any implementation, or whether it would be legal to build an implementation that, for instance, has no preference among alternatives. I propose that since the empty pattern is no longer legal (and about time), we use "|" in patterns to indicate alternation without preference, and "||" to indicate "try the first, then the second, etc". So "cat dog fox" ~~ /( fox | dog | cat )/; might match any of the three, and in fact is quite likely to match cat (since scanning the string could be a very long process), but "cat dog fox" ~~ /( fox || dog || cat )/; would be guaranteed to first try fox, then if that fails backtrack and try dog, and if that fails backtract to try cat. The choice of symbols parallels the junction and short-circuiting or operators, and in most cases when an alternation is specified, the programmer has no preference among the alternatives (indeed, in most cases only would could match anyway), so it seems silly to force the engine to prefer the first one. I'm imagining that in the first example, the implementation would probably build an FSA and process each letter as it comes, while the second would rely on backtracking. What think you all? -- Adam Lopresto http://cec.wustl.edu/~adam/ There's too much blood in my caffeinestream.
Lexically scoped methods (was: L2R/R2L syntax)
The question is, can I create a method on a class with a different scope than
the class itself has? Put another way, it seems like
module ArrayMath;
sub sum(Array $this){
$this.reduce(operator::+, 0);
}
method Array::sum(;){
.reduce(operator::+, 0);
}
(modulo syntax errors) then both should have the same visibility (ie, module
level only, unless they're somehow exported (what's that in perl6, "is
public"?)). So the question of namespace becomes moot, because just because
it's a method on Array doesn't mean it's accessible anywhere a similar sub
wouldn't be. Either could be exported and made globally available, but I don't
see why they should have to be. Or am I missing something?
> On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote:
> >
> > On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote:
> > > If the function form of map/grep were to be removed, which has been
> > > suggested,
> > > and the <~ form maps to methods. How would you go about defining a
> > > utility
> > > module similar to List::Util that uses the same syntax as map/grep but
> > > without making the subs methods on the global ARRAY package ?
> >
> > If you want the method to be available everywhere,
>
> But I don't
>
> > you probably
> > _should_ make it a method of the global Array class.
>
> Thats like trying to wite a whole perl5 application in main
> without any packages
>
> > More typically,
> > perhaps, you'd only be using your new method to operate on certain
> > arrays that you use, in which case you would make a new class for those
> > particular arrays, so your new method would work only on the specific
> > arrays you intended it to:
>
> Thats not always possible. Those Arrays may be passed to me from
> somewhere else, so I have no control over thier class.
>
> > I don't see any problem (other than maybe a philosophical objection)
> > with making them methods of Array, though, if they're valuable enough.
> > That certainly would seem the common Perl thing to do.
>
> No, namespaces were invented for a reason.
>
> Graham.
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All of our customer service representatives are on vacation. Please hold for
the next available representative.
Re: L2R/R2L syntax
I'd like to point out one thing that I'm not sure of. It seems like the
original proposal only allowed for the operators to change terms around.
So given the same (1)-(4) from the message, (4) is exactly the same as (1), and
(2) and (3) are exactly the same as each other and as
@out = @in.map({ ... }).grep({ ...}); # (5)
I guess what I'm trying to point out is that the user still has to know which
syntax is really natively supported, and can only use ~> and <~ as crutches for
reversing that. IOW, we can't just eliminate the global "map {block} @list"
function, or "@list ~> map {block}" simply won't work (but could be written as
"@list.map({block})". Somehow this feels even more confusing than ever.
> So, to bring this thread back on track *again*, I hopefully offer this
> summary.
>
>
> 1) Damian's idea of using ~> and <~ as L2R and R2L is well-liked. Thus:
>
>@out = grep { ... } map { ... } @in; # (1) (perl5)
>
> becomes any of the following:
>
>@out = grep { ... } <~ map { ... } <~ @in; # (2) (perl6)
>
>@out <~ grep { ... } <~ map { ... } <~ @in; # (3)
>
>@in ~> map { ... } ~> grep { ... } ~> @out; # (4)
>
> My impression was that this was _instead_ of (1), eliminating the
> specialized syntax of the map, grep, etc. functions in favor of this
> more generic piping syntax, but that wasn't explicitly stated. Is that
> correct?
>
> 2) You might be able to combine L2R and R2L piping in one statement.
> Maybe.
>
> 3) How pretty you think the above is depends almost entirely on how the
> tilde is rendered in your font.
Yes, it wasn't until I got on a different computer with ~ centered that I
understood why anyone even conceived of this. But Unicode is worse, since I
have NEVER gotten ANY of those to work. Apparently my gnome-terminal/ssh/less
combination just doesn't like unicode. But this is perl, so who cares if
anyone can read it, right?
>
> 4) Some people like the idea of having Unicode operators in perl6.
> Some don't. There are issues with it. Larry hasn't come up with a
> ruling yet. We should wait for his decision.
>
> 5) Sarcasm is, apparently, dead.
I'm not dead yet! I'm feeling much better, really.
>
> MikeL
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
What exactly do we mean when we use the word "semantics"?
Re: right-to-left pipelines
> It seems to me that the simplest disambiguating rule is to require the > parentheses on methods. The way I see it, any sort of matching of what [multi-]?method is to be called, is automatically doomed to failure. But I don't think that means we need to require parentheses, except to override the default behaviour. There are three meanings I can see for parenthesisless calls that are completely regular and meaningful, easy to read, and quite (debatably) good things. 1) Always assume nulladic. That is, $obj.id is always parsed exactly like $obj.id(). The advantage here is that short simple things can be written short and simply. 2) Always assume monadic. Personally, I don't think this would be that useful, but I'm mentioning it for completeness. Any call that doesn't have parentheses scoops up the next argument only. 3) Always assume variadic. Basically a lot like the perl5 rule. If you call something without parentheses, the parser puts parentheses around pretty much everything after it. If you don't like it, put your own parentheses where you really want them. So foo bar baz quux; would be parsed as foo(bar(baz(quux(; and foo bar, baz; would be exactly like foo(bar(), baz()); and if foo is later determined to be something that can only take one argument, well then too bad. The idea is that leaving off the parentheses is just shorthand, and doesn't need to do any lookup to determine whether what's typed is valid, any more than if you had typed foo(bar(), baz()); If you want foo to be monadic, call it as "foo(bar), baz"; or the lispy "(foo bar), baz;" (with optional parens after bar and baz, since they don't have anything more they could eat anyway, unless someone gets crazy enough to write a unary comma operator). So basically we can leave off the parentheses in the usual cases, but they're still required when you're doing something unusual or that would otherwise be hard to read. -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ "I have a very firm grasp on reality! I can reach out and strangle it any time!"
Re: right-to-left pipelines
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Of course, that means that grep and sort and part are all methods of the Array
class, so the standard way to write them would be
grep @a: {$_ > 0};
instead of
grep {$_ > 0} @a;
H. Odd. I'm guessing it wouldn't be possible to extend the indirect
object syntax to allow
grep {$_ > 0} @a:;
(object can go anywhere in argument list, so long as it's marked with a :. But
now I'm trying to speculate about Larry's colon, something best left to
others).
But somehow it seems like an increase in readability, especially if things were
renamed. Imagine renaming "grep" to "where" or "suchthat". And then the
antigrep can be "except".
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
If God didn't want us to eat animals, he wouldn't have made them out of
meat!
Re: purge: opposite of grep
I like it except for the name, which feels too active to me (ie, if I were to
purge those elements from the array I'd expect the array to be altered, instead
of returning a new array with only those elements). But I do like the idea. I
think the name "except" would be pretty nice, though. Then again, I'm not too
terribly fond of "grep". If it were named "only", then things might be really
nice. (Or we could name them "accept" and "except" and be mean :))
> SUMMARY
>
> Proposal for the "purge" command as the opposite of "grep" in the same way
> that "unless" is the opposite of "if".
>
> DETAILS
>
> I've lately been going a lot of greps in which I want to keep all the
> elements in an array that do *not* match some rule. For example, suppose
> I have a list of members of a club, and I want to remove (i.e. "purge")
> from the list everybody for whom the "quit" property is true. With grep
> it's done like this:
>
>@members = grep {! $_->{'quit'}} @members;
>
> Obviously that works well enough, but just like "unless" somehow
> simplifies the logic by removing that leading !, "purge" can simplifiy the
> array filter:
>
>@members = purge {$_->{'quit'}} @members;
>
> FWIW, I came up with "purge" because my first inclination was to spell
> "grep" backwards: "perg". :-)
>
> -miko
>
>
> Miko O'Sullivan
> Programmer Analyst
> Rescue Mission of Roanoke
>
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
I love apathy with a passion.
--Jamin Gray
Re: Unifying invocant and topic naming syntax
> > My favorite was from ages ago:
> >
> > sub bar(;$foo //= $_) {...}
>
> I think that today that would be written more like this:
>
> sub bar(;$foo) is given($def_foo) {
> $foo = $def_foo unless exists $foo;
> ...
> }
>
> Though we might get away with:
>
> sub bar(;$foo = $def_foo) is given($def_foo) {
> ...
> }
It seems like that would be useful and common enough to write as
sub bar(;$foo is given) {
...
}
Where $foo would then take on the caller's topic unless it was explicitly
passed an argument.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Never be afraid to tell the world who you are.
--Anonymous
Re: Superpositions and laziness
I still prefer "cached", which sounds less lingo-ish than "memoized" but reads
better than "same" ("Same as what?").
> Billy Naylor asked:
>
> > Would it be useful to apply memoization in a similar fashion...
> >
> > sub square ( Num $n ) is memo {
> > return $n ** $n;
> > }
>
> Yes. Larry indicated this in A2
> (see http://search.cpan.org/perl6/apo/A02.pod#Properties).
>
> The name of the property is still under debate. Larry favours:
>
> sub square ( Num $n ) is same {...}
>
> whereas others feel that:
>
> sub square ( Num $n ) is memoized {...}
>
> is more appropriate.
>
> Damian
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
"I cannot read the fiery letters," said Frodo in a quavering voice
"No," said Gandalf. "But I can. The letters are Elvish, of an ancient mode,
but the language is that of Laywers, which I will not utter here. But this in
the Common Tongue is what is said, close enough:
If at any time you are not completely satisfied with your One Ring product,
return it to its point of manufacture at the Cracks of Doom, in the Land of
Mordor, where the Shadows lie, for a full refund."
Re: list comprehensions
> I don't see why I'd want to do it with arrays, but...
>
> %a_students = %grades{grep /^a/i, keys %grades};
Looks like that's just the same as
%a_students = grep {.key ~~ :i/^a/}, %grades.kv;
(after adjusting for perl6 syntax for a few things)
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Aleph-null bottles of beer on the wall,
Aleph-null bottles of beer,
You take one down, and pass it around,
Aleph-null bottles of beer on the wall.
Re: UTF-8 and Unicode FAQ, demos
I'm having trouble this is even being considered. At all. And especially for these operators... > So, yeah, include trigraph sequences if it will make happy the people > on the list who can't be bothered to read the documentation for their > own keyboard IO system. > > But don't expect the rest of us to use them. So you're one of the very few people who bothered to set up unicode, and now you want to force the rest of us into your own little "leet" group. Given the choice between learning how to reconfigure their keyboard, editor, terminal, fonts, and everything else, or just not learning perl6, I bet you'd have a LOT of people who get scared away. Face it, too many people think perl is linenoise heavy and random already. Which brings me to my real question: why these operators? It's not as if they're even particularly intuitive for this context. They're quotes. They don't mean "vector" anything, and never have. I could almost see if the characters in question just screamed the function in question (sqrt, not equals, not, sum, almost anything like that), but these are just sort of random. Given how crazy this is all getting, is it absolutely certain that we're better off not just making vector operations work without modifiers? I reread the apocalypse just now, and I don't really see the problem. The main argument against seems to be "perl5 people expect it to be scalar", but perl5 people will have to get used to a lot. I think the operators should just be list based, and if you want otherwise you can specify "scalar:op" or convert both sides to scalars manually (preferably with .length, so it's absolutely clear what's meant). -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Who are you and what have you done with reality? --Jamin Gray
Re: perl6 operator precedence table
This is exactly what I wanted .= for.
@array .= splice(2,0,$element); # in-place, @array = @array.splice
@new = @array.splice(2,0,$element);
$sentence .= lcfirst;
The semantics are pretty clear, then it's just up to the compiler to optimize
it for in-place. Perhaps functions could override the default
method splice (...) { #general function for making a new string
method splice (...) is inplace { #overloading to optimize for in-place
but that might be going a bit too far.
> I would, however, point out that other methods could
> potentially have modify-in-place and a copy-and-modify
> variants:
>
> @array.splice(2,0,$element); # in-place
> @new = @array.splice(2,0,$element); # on copy
>
> $str.chomp; # in-place
> $new = $str.chomp;# on copy
>
> $str.lcfirst; # in-place
> $new = $str.lcfirst; # on copy
>
> @array.map({ %trans{$^a} }); # in-place
> @new = @array.map({ %trans{$^a} }); # on copy
>
> So we might want to look for a more general solution.
>
> Unfortunately, one can't just generalize and use
> void/non-void context to determine the correct behaviour,
> since in-place matches and substitutions still need to
> return their match object:
>
> $matched = $str.replace(/foo/ -> { 'bar' }); # in-place
> $newstr = $str.replace(/foo/ -> { 'bar' }); # on copy
>
> One could perhaps change the verb to a participle:
>
> @array.splice(2,0,$element); # in-place
> @new = @array.spliced(2,0,$element); # on copy
>
> $str.chomp;# in-place
> $new = $str.chomped; # on copy
>
> $str.lcfirst; # in-place
> $new = $str.lcfirsted; # on copy
>
> @array.map({ %trans{$^a} }); # in-place
> @new = @array.mapped({ %trans{$^a} }); # on copy
>
> $matched = $str.replace(/foo/ -> { 'bar' }); # in-place
> $newstr = $str.replaced(/foo/ -> { 'bar' }); # on copy
>
> but I doubt that would be well accepted. ;-)
>
> Or one could define a copy-the-invoke method call operator (say, C<+.>):
>
> @array.splice(2,0,$element); # in-place
> @new = @array+.splice(2,0,$element); # on copy
>
> $str.chomp;# in-place
> $new = $str+.chomp;# on copy
>
> $str.lcfirst; # in-place
> $new = $str+.lcfirst; # on copy
>
> @array.map({ %trans{$^a} }); # in-place
> @new = @array+.map({ %trans{$^a} }); # on copy
>
> $matched = $str.replace(/foo/ -> { 'bar' }); # in-place
> $newstr = $str+.replace(/foo/ -> { 'bar' }); # on copy
>
>
> > In typical topical string usage, that leaves us with
> >
> > if .subst/a/b/ {...}
> > $result = .where/a/b/
> >
> > That's quite livable, though the second is a bit odd, English-wise.
> > We could even keep around
> >
> > s/a/b/
> >
> > as a shorthand for .subst/a/b/.
>
> Oh, I definitely think so!
>
>
> > And maybe even add
> >
> > w/a/b/
> >
> > as a synonym for .where/a/b/.
>
> Hm. *s*ubstitute and *w*eplace. ;-)
>
> Damian
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
I just want a plate and a fork and a bunny...
Re: perl6 operator precedence table
Really what I've been wishing for was an operator (or whatever) to let me do an s// without changing the variable. print 'He said "'_($statement ~ s/\.$//)_'," but we didn't believe him.'; I'm not sure exactly what the semantics would be, but somehow =~ without the = seems appealing...it's always seemed annoying to have to make a new variable for things like that, instead of being able to do it in place. But then, perhaps that isn't justification for an entire operator so much as $statement.replace/\.$// or something Mental note: no more postings right before bed. > Brent Dax wrote: > > > Can the new nefarious use be concat? Pretty please? > > There was a brief period 18 months ago when tilde *was* the designated > Perl 6 concatenation operator. > > I certainly wouldn't mind seeing it return to that role, now that > it's not needed elsewhere. And, of course, that would actually be: > > $x ~ $y string concatentation > $x ~= $ystring append > ~$x stringification > > I guess the only concern is the potential for nasty surprises between: > > $str =~ s/a/b/; substitute a for b in $str > > and: > > $str ~= s/a/b/; substitute a for b in $_ and append result to $str > > But I guess that's no worse than: > > $x-=10; > > and > > $x=-10; > > which doesn't seem to be a problem for people in Perl 5. > > Damian > > -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Falls don't kill people. It's the deceleration trauma.
Re: perl6 operator precedence table
> : It's rare enough to need bitwise things in Perl 5 (outside golf). I'm > : hoping that it'll be even rarer in Perl 6, as better interfaces are > : designed for the things which at present require flipping individual > : bits. > > I almost wonder if it's wrong to waste ~ on it... > > That would be an argument for b| and b&, I suppose. That looks like about the best. When rare things get too punctuation-heavy, people start to get really confused. What I'd expect is that a lot of what's now done bitwise could be done with overloading of superpositions (combining flags and such, although in a lot of cases & and | would be swapped. Then again, it always seemed odd that you combine two flags with | to turn them both on). There could probably be a bitwise type that would overload superpositions to do bitwise math instead... my Bitwise $a = 1; #woohoo, $a and $b are no longer magical! my Bitwise $b = 3; print $a & $b; #prints 3 So if you really need to do a lot of bitmath, you use the special types, and otherwise you can be barely aware that they exist. sysopen($handle, $filenmae, O_CREAT & O_RDRW); -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ "We've secretly replaced the dilithium with Folgers Crystals."
Re: Prototype-Based Inheritance (was Re: Indeterminate math)
Would it make sense for the syntax to be more like
my $obj3 = $obj.new;
Of course, that would kill my ".= new" idea for instantiation (since it would
call an instance-based new instead of class-based), but I'm getting less fond
of that syntax anyway (though I think .= should definitely be supported in the
language, and $a .= foo; should DTRT, ie, $a = $a.foo).
>
> On Monday, October 14, 2002, at 07:54 PM, Mark J. Reed wrote:
> > Heh, indeed. :) But seriously, you could do worse. JavaScript
> > receives
> > a lot of (IMHO) undeserved criticism. The name is a blatant marketing
>
> No, I've had to use it off-and-on for the past year... it deserves it.
> :-) But enough of that.
>
> I agree, prototype based inheritance is really useful sometimes.
> (Those of you not subjected to JS may be more familiar with
> Class::Classless, a quite nice perl5 implementation.)
>
> I'd definitely like to see builtin support for instance based
> inheritance. I've found many, many uses for Class::Classless, and have
> made halfbreed variations of it for several special-case situations.
> IMO the best situation would be to have both worlds collide; not
> strictly class-based, not strictly proto-based, but a mix-and-match of
> each in accordance to the particular problem you're trying to solve.
>
> An interesting way to do this could simply be to allow object
> instances, as well as normal classes, in the inheritance tree; you
> could then mix a prototype-based object with, for example, several
> class-based mixin behaviors, etc.
>
> Something like:
>
>my $obj = Something.new;# (1) obj based on a class
>
>class MyClass is $obj {...} # (2) a class based on an obj!
>
>my $obj2 = MyClass.new; # (3) obj based on a class based on
> an obj
>
>my $obj3 isa $obj; # (4) an obj based on another obj
>
>my $obj4 isa $obj isa MyClass; # (5) obj + mixin (but what syntax???)
>
>
> Note that (2) would have interesting implications if you changed $obj
> runtime, but would be very uncommon. (4,5) could be quite common, tho.
> And (4,5) need to use a word other than 'is', which means that
> currently none of these syntaxes look anything alike. :-P
>
> Mixing OO frameworks is quite useful in some real-world situations.
> Sometimes it's more efficient to change your OO implementation than to
> try to translate your problem to fit the one you're given.
>
> MikeL
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All I want is a warm bed, a kind word, and unlimited power.
Re: Indeterminate math
Sounds like a good place for "fail", as described in Exegesis 4, so that it could be taken as undef or an exception depending on pragmata. > This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would > produce a divide by zero error in Perl 6, or if it would return a value > representing an indeterminate result (undef?) It would make more sense for > Perl, upon being given a simple bit of impossible math, to return undef > (like other functions do on failure) than to generate an error. The error > seems a throwback to earlier days of hardwired calculators. > > If nothing else it would make guarding against indeterminate math easier. > Rather than the user having to trap an error, or do possibly complicated > work to see if any of the denominators might be zero, you can just see if > the result is undef. > > > [1] I apologize for forgetting who. > > [2] Discussion of divide by zero and why it's not infinity [3] > http://mathforum.org/dr.math/faq/faq.divideby0.html > > [3] I was always taught it's infinity. > > -- > > Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ > Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One > Don't worry, baby, my wrath can be pretty groovy. > http://www.goats.com/archive/980804.html > -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Who are you and what have you done with reality? --Jamin Gray
Re: untaintby property
I'd say the correct solution isn't to control which modules can accidentally untaint data (it seems pretty likely that no matter what we do, maliciously coded modules will be able to screw you over if they try to do so intentionally) but rather fix those aspects of tainting that allow any module to accidentally untaint data. Personally, I think untainting data should only be the result of an explicit "untaint" function, but maybe that's going too far. -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Her hair glistened in the rain like nose hair after a sneeze. (Chuck Smith, Woodbridge)
Re: Passing arguments
Personally, I like the looks of
sub foo($a, $b is given) { ... }
> Does this mean that we allow/encourage uses of $_ other than as a default
> for an optional argument? I think it would be less confusing and
> error-prone to associate the underscore-aliasing with the parameter $_
> will be replacing, i.e. this
>
> sub foo($a, $b = given) { ... }
>
> vs this
>
> sub foo($a; $b) is given($b) { ... }
>
> or this
>
> sub foo($a; $b) is given($c) {
> $b //= $c;
> ...
> }
>
> Furthermore, if the caller can pass undef for the second parameter, I
> don't see a way to distinguish in the third variant between a legitimately
> passed undef, for which we don't want $_, and a missing optional argument,
> for which we do.
>
> /s
>
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
"It's times like these that I wish I was a leper" --Bob.
Re: Suggestion for perl 6 regex syntax
Some regexpes will be longer, but a lot will benefit from the changes, by being
shorter or clearer, or often, both. The problem with your suggestion is you're
making assumeptions about what's common and what's not (character classes more
common than closures, for instance) that probably aren't accurate. You could
certainly make your own and rules, but I bet most people won't
use them nearly enough for that sort of shortening.
Also, your sample regexps aren't exactly fair, because you're using capturing
groups all over the place for things that I'm pretty sure you don't really want
to capture, just to group. So your perl5 would have to be rewritten from
/^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/ #50 chars
to
/^([+-]?)(?=\d|\.\d)(\d*(?:\.\d*)?)(?:[Ee]([+-]?\d+))?$/ #56 chars
(capturing sign, mantissa, and exponent: you could capture differnt things if
you want, or you could capture nothing. But capturing random things just
because they save you a few keystrokes isn't a good practice)
We could golf that down to
/^(+|-)?(?=\d|\.\d)(\d*(?:\.\d*)?)(?:E([+-]?\d+))?$/i #53 chars
if you really care about every last character.
The perl 6 equivalent becomes
:i/^(+|-)?(\d*[\.\d*]?)[E([+|-]?\d+)]?$/ #56 chars
So you're not losing much at all. That is, if you really want to spend forever
fighting for every last character. The point is, when you use unusual
contructs like lookaheads you pay a price in order to get more clarity. When
you use common/good things like non-capturing parens, you are rewarded in fewer
keystrokes.
Also note that we could dramatically rewrite the pattern, and instead of doing
a lookahead assertion we can use an actual code assertion to assert that the
mantissa isn't empty, making the new perl6 code actually shorter than the
(correct) perl5 version. Of course, that's because we use perl6's strengths.
:i/^(+|-)?(\d*[\.\d*]?)<($2=~/./)>[E([+|-]?\d+)]?$/#51
> While Apocolypse 5 raises some good points about problems with the old regex
> syntax, its new syntax is actually worse than in perl 5. Most regexes, such
> as this one to match a C float
>
> /^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/
>
> would actually become longer:
>
> /^(<[+-]>?)\d*(\.\d*)?(<[Ee]>(<[+-]>?\d+))?$/
>
> Therefore I propose a few minor changes:
>
> character class: [...]
> non-captured group: {...}
> closure: <{...}>
> lookahead assertion:
> lookbehind assertion:
>
> This would bring the aforementioned regex back down to perl 5 size, and many
> would become even shorter than in perl 5.
>
> __
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Dreaming permits each and every one of us to be quietly and safely
insane every night of our lives.
--William Dement
Re: auto deserialization
> On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>
> >> my Date $date .= new('Jun 25, 20002');
> >
> > H. That's a very interesting idea.
> > I like it.
>
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> now means "use the class I just mentioned".
Not quite. .= means exactly what you'd expect it to mean, "call a method on
the object on the left and assign the result to the variable on the left". So
$date .= new('Jun 25, 2002');
means exactly the same as
$date = $date.new('Jun 25, 2002');
(I'd expect .= to be a valid operator anyway, so one could do $linked_list_item
..= next(), but that's beside the point).
The utility comes when $date.new() calls the (static) new function on the Date
class even if $date is undef. (In essence, "my Date $date;" makes $date an
interesting value of undef, one that's not defined but has a .class() value).
Of course, this doesn't do anything in particular for constructors. We could
also call any static class function on that object.
> If so, perhaps it would only be a small step further for
> it to also mean "and if I don't give the name of the method,
> use new_from_[class of object being passed]". So, the following code
> would call Date::new_from_String, passing 'Sep 21, 1963' as the
> sole argument:
>
> my Date $date;
> $date .= 'Sep 21, 1963';
The problem is that it's not just for static functions. The point is that
"$date .= foo" would be exactly like "$date = $date.foo", and having an
implicit constructor seems really messed up. I guess that would mean that I
could pass Date.'Sep 21, 1963' to anything expecting a Date object. I think
that might be just slightly too magical for comfort. I don't like the idea of
object types automagically converting themselves by context; that way madness
lies. If you want "new" just call it.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Why does man kill? He kills for food. And not only food: frequently
there must be a beverage.
-- Woody Allen, "Without Feathers"
Re: auto deserialization
> And, furthermore, that you could easily define special semantics
> for void-context constructor calls via undef'd but typed variables,
> so that you could just write:
>
> (my Date $date).new('June 25, 2002');
>
> and have the interpreter autovivify the object.
That's pretty close to what I was thinking of, but I don't think the
constructors actually have to be special. What if "my Date $date;" lets the
compiler know that $date belongs to the Date class, even if it's undef? If
that's the case you could call static functions as $date.foo() instead of
Date.foo(), and therefore your constructor call would be simply
my Date $date .= new('Jun 25, 20002');
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
perl -le '$_=(split q,",,`$^Xdoc -q japh`)[1].".";y/pj/PJ/;print'
