Re: Formal Parameters To While Block
Juerd writes:
Luke Palmer skribis 2005-04-26 9:37 (-0600):
sub statement:while (cond is lazy, block) {
How does that handle
for { closure }, { closure } - { ... }
and why? :)
Umm... maybe I'm totally misunderstanding you, but I think it doesn't,
since I'm implementing statement:while, not statement:for.
Luke
Re: Formal Parameters To While Block
Luke Palmer skribis 2005-05-01 1:17 (-0600): Umm... maybe I'm totally misunderstanding you, but I think it doesn't, since I'm implementing statement:while, not statement:for. Sorry, I wasn't clear enough. How would the same is lazy thing be useful with for, given this example? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Formal Parameters To While Block
Juerd writes:
Luke Palmer skribis 2005-05-01 1:17 (-0600):
Umm... maybe I'm totally misunderstanding you, but I think it doesn't,
since I'm implementing statement:while, not statement:for.
Sorry, I wasn't clear enough. How would the same is lazy thing be
useful with for, given this example?
Ahh. It wouldn't. Which is a pretty good example of why is lazy is
the wrong name.
is lazy is used for the condition of while, the right side of || and
, etc. It is for when you pass a closure without putting braces
around it.
Well, almost like that. We still have to handle:
while my $line = = {...}
# $line still in scope
Which is different from:
statement:while({ my $line = = }, {...});
# $line not in scope
Anyway, for doesn't need is lazy, because it simply evaluates the
list it is given and iterates over it. The fact that evaluating the
list may be a no-op because of laziness is unrelated to is lazy
(another hint that it's the wrong name).
Luke
Re: Formal Parameters To While Block
On 5/1/05, Luke Palmer [EMAIL PROTECTED] wrote: Anyway, for doesn't need is lazy, because it simply evaluates the list it is given and iterates over it. The fact that evaluating the list may be a no-op because of laziness is unrelated to is lazy (another hint that it's the wrong name). To start off the name game: `is deferred`? `is closure`, `is coderef`, `is sub`? `is condition`? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Junctions of classes, roles, etc.
On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote: Aaron Sherman [EMAIL PROTECTED] wrote: On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote: That would be absolutely horrible. Str|Int is simply the type of Yes|1, isn't it? That would certainly make signature matching on different kinds of junctive types trivial. Nope. You all seem to have some very strong opinions, and I'm unable to have a discussion around absolutes like absolutely horrible and nope, so all hypotheticals aside, I'll just concede that this is an uninteresting way to spend our time.
Re: Junctions of classes, roles, etc.
On Sun, May 01, 2005 at 10:59:59AM -0400, Aaron Sherman wrote:
On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
That would be absolutely horrible.
You all seem to have some very strong opinions, and I'm unable to have a
discussion around absolutes like absolutely horrible and nope, so
all hypotheticals aside, I'll just concede that this is an uninteresting
way to spend our time.
Sorry. I'll watch my language better in the future, and provide better
rationales to support my opinion. :-/
In this case, the reason I called this absolutely horrible:
my Str|Int $x;
$x.method(); # calls .method twice
Is because to me, it is conceptually no difference to:
sub foo (Str|Int $x) { $x.method() };
In both cases, the junctive type is used to construct a new type that is a
supertype of both Str and Int, for type checking purposes. If it
silently promotes the variable itself to a Junction for autothreading,
that will render such type construction unusable, as it will be doing
two highly orthogonal things with a single syntax.
Again, my apologies for using strong words without adequate justification.
Thanks,
/Autrijus/
pgpvkCR2varmo.pgp
Description: PGP signature
Re: Junctions of classes, roles, etc.
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
On Fri, 29 Apr 2005, Brent 'Dax' Royal-Gordon wrote:
David Storrs [EMAIL PROTECTED] wrote:
Could we see some code that shows why this is a good idea? My initial
reaction is horror; I can very easily see huge numbers of subtle,
hard-to-reproduce bugs coming out of this.
I'm quite willing to believe that there are [good results], but I'm not
coming up with them.
What do you think this is?
sub foo(Str | Int $bar) { ... }
I believe you mean sub foo(Str^Int $bar){...} ( something that is Int or
Str but not both). But that, too, just reduces the amount of code and is
merely a shortcut for:
multi sub(Str $bar){...}
multi sub(Int $bar){...}
I do not see how any auto-threading occurs in that code. It is completely
innocuous in that sense, and I don't think that is what horrified
David.
Indeed, you're right on the money, Abhijit. Thanks for stating it so
well.
Let's move this away from simple types like Str and Int for a moment.
Tell me what this does:
class Tree {
method bark() { die Cannot instantiate a Tree--it is abstract! }
}
class Birch {
method bark() { return White, papery }
}
class Oak {
method bark() { return Dark, heavy }
}
class Dog {
method bark() { print Woof, woof!; return bow wow }
}
class AlienBeastie isa Tree isa Dog {}
class WhiteAlienBeastie isa Birch isa Dog {}
class HeavyAlienBeastie isa Oak isa Dog {}
sub Foo(Tree|Dog $x) { $x.bark() }
Ignore for the moment that this is stupid code--it's semantically and
(AFAIK) syntactically valid. So, what happens when I do each of these:
Foo( new AlienBeastie() );
Foo( new WhiteAlienBeastie() );
Foo( new HeavyAlienBeastie() );
??
--Dks
