Re: Google index and subsets (two topics for the price of one!)
HaloO, On Monday, 16. June 2008 10:11:49 Ovid wrote: > For example, should the pre/postfix '++' be > listed as having a side-effect? I think so. But the scope where these side-effects take place is important as well. In your second example below the side-effect is restrained to the subs scope. That should be considered harmless. The more global a side-effect takes place, the more you get into spooky action at a distance and unpredictable behavior. > sub side_effect{ return $_[0]++ } > sub no_side_effect { my $x = shift; return $x++ } > > In Perl 6, since arguments to subs would have to be specifically > written as 'is rw', we might be able to minimize this issue, but I > don't know if we can stop it. I would think that it should be possible to enforce methods that don´t modify the invocant mostly at compile time. The rest could use a STORE instrumentation on MOP level that fails on any modification. Then a where clause could temporarily install that for the evaluation of its body. Also access to outer namespaces can easily be blocked or restricted. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Google index and subsets (two topics for the price of one!)
--- TSa <[EMAIL PROTECTED]> wrote: > Daniel Ruoso wrote: > > In fact, I doubt that there's a way to completely avoid any > possible > > side effects on this closures. as the very first line of the > closure > > shows: > > > >$_.inside_of(...) > > > > This is a plain method call, there's no way to tell if this method > > will change anything inside the object or not. > > Well, we could use something to the effect of const methods in C++. > That is we have a trait on a method that prevents changes of the > object. And these could be the only ones allowed in where blocks. The problem Daniel mentions is that in a dynamic language like Perl, you just can't prevent side-effects. Consider: eval $foo; Does that have side effects or not? There's no way to know and yet there are plenty of examples one could potentially construct which would have non-obvious side-effects. I would love to be able to introspect the code to know whether or not any operators or keywords with known side-effects are in a given block of code, but even then that would depend on the context (of the code, not Perl's "context"). For example, should the pre/postfix '++' be listed as having a side-effect? sub side_effect{ return $_[0]++ } sub no_side_effect { my $x = shift; return $x++ } In Perl 6, since arguments to subs would have to be specifically written as 'is rw', we might be able to minimize this issue, but I don't know if we can stop it. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Google index and subsets (two topics for the price of one!)
--- TSa <[EMAIL PROTECTED]> wrote: > I must admit that I hardly follow that statement. Why are > side-effects > essential to achieve constraint programming and why do you think that > the way to get at the constraint programming paradigm are the subset > type definitions? Because I can't think of any other way to do it :) > E.g. to get constraint programming as I know it > from Oz, Perl 6 would need a single assignment store first of all. And > then a heavy re-assignment of semantics to things like '$x = $y' which > would become a symmetric assertion instead of asymmetric, imperative > assignment. Now it's my turn to say that I can't follow that statement. > Could you give some hints on these fascinating wins, please. I explain in more detail at http://use.perl.org/~Ovid/journal/36667 You asked why I think that constraints would need to modify the variable (would "invocant" be the right term here?). In logic programming, constraints merely help prune search tress to a reasonable amount. Nothing is mutated (as far as I'm aware). In imperative or OO code, I would think that a constraint *must* be mutating or else you have little more than DBC (design by contract). Am I missing something fundamental here? Examples welcome. Cheers, Ovid I for > my part would argue the where blocks to be a very constraint form of > block that generally has type :(Object --> Bool) and doesn't alter > the object of concern in any way. Note that the where blocks are > executed from within the type-checker or the dispatcher where no > assumptions of the call environment other then the object should > be made. > > > Regards, TSa. > -- > > "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare > "Simplicity does not precede complexity, but follows it." -- A.J. > Perlis > 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan > -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Google index and subsets (two topics for the price of one!)
HaloO, Daniel Ruoso wrote: In fact, I doubt that there's a way to completely avoid any possible side effects on this closures. as the very first line of the closure shows: $_.inside_of(...) This is a plain method call, there's no way to tell if this method will change anything inside the object or not. Well, we could use something to the effect of const methods in C++. That is we have a trait on a method that prevents changes of the object. And these could be the only ones allowed in where blocks. It's important to remember that, in Perl 6, something is only guaranteed to be fully executed before the next statement when using short-circuit operators, everything else is subject to eventually be made lazy, with the exception of the feed operators, that explicitly say to assume lazy behaviour. So, no C++ sequence points or the like at all in the definition of Perl 6? Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Google index and subsets (two topics for the price of one!)
HaloO, Ovid wrote: In other words, I think we could get proper constraint programming if a subset can mutate its variable. Otherwise, all assignment would need to be wrapped inside of an eval and the code would be more bug-prone. I must admit that I hardly follow that statement. Why are side-effects essential to achieve constraint programming and why do you think that the way to get at the constraint programming paradigm are the subset type definitions? E.g. to get constraint programming as I know it from Oz, Perl 6 would need a single assignment store first of all. And then a heavy re-assignment of semantics to things like '$x = $y' which would become a symmetric assertion instead of asymmetric, imperative assignment. Will said mutating work? If it does, all logic handling constraints can be encapsulated in one spot. On the other hand, this could lead to mysterious action at a distance. The losses are significant, but the wins seem absolutely fascinating. Could you give some hints on these fascinating wins, please. I for my part would argue the where blocks to be a very constraint form of block that generally has type :(Object --> Bool) and doesn't alter the object of concern in any way. Note that the where blocks are executed from within the type-checker or the dispatcher where no assumptions of the call environment other then the object should be made. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Google index and subsets (two topics for the price of one!)
Seg, 2008-06-09 às 23:09 +0100, Ovid escreveu: > Well, looking at the examples that you and Jonathan listed, I see I > should refine my question. For example: > subset Crosshair of Point where { > $_.inside_of($target_area) > || > $target_area.has_moved > ?? $_.move_inside($target_area) > :: $target_area.move_outside($_) > }; > In other words, I think we could get proper constraint programming if a > subset can mutate its variable. Otherwise, all assignment would need > to be wrapped inside of an eval and the code would be more bug-prone. > Will said mutating work? If it does, all logic handling constraints > can be encapsulated in one spot. On the other hand, this could lead to > mysterious action at a distance. The losses are significant, but the > wins seem absolutely fascinating. In fact, I doubt that there's a way to completely avoid any possible side effects on this closures. as the very first line of the closure shows: $_.inside_of(...) This is a plain method call, there's no way to tell if this method will change anything inside the object or not. Obviously, in most cases this kind of constraint checking won't make any change in the value. it's a dangerous feature, I agree, but it's a price we pay for many other interesting features, and in fact, some neat things can be implemented using this dangerous thing itself. Lazy evaluation is certainly something that will benefit from that. Imagine that inside_of depends on the result of some IO, the object can use non-blocking IO, return immediatly and only do the actual reading if that value is needed, and at that point, the information might even be already available, so no blocking is ever needed. Or inside_of might never be called and no IO is ever performed, and this simply defined by if that value is bound to a variable of a given type (like in a signature matching). It's important to remember that, in Perl 6, something is only guaranteed to be fully executed before the next statement when using short-circuit operators, everything else is subject to eventually be made lazy, with the exception of the feed operators, that explicitly say to assume lazy behaviour. lazyness is probably the most important perspective change from p5 to p6, take a look at the code for the default P6 meta class I'm working in SMOP (the introspection methods, in the end): http://svn.pugscode.org/pugs/v6/smop/src-s1p/P6Meta.pm daniel
Re: Google index and subsets (two topics for the price of one!)
Seg, 2008-06-09 às 23:36 +0100, Ovid escreveu: > --- Jonathan Worthington <[EMAIL PROTECTED]> wrote: > > By default, block parameters (including $_) are readonly, > I hope that is a deep readonly? In other words, if $_.position returns > an array reference, can I mutate a value in that reference and the > state of $_ is thereby changed? Even having said that in the other mail in this thread, I'd like to stress the fact that *it's not possible to avoid side-effects of a method call*, if that method call have a side effect (even if a "inside effect"). And again, some neat things will only be possible because of that. daniel
Re: Google index and subsets (two topics for the price of one!)
--- Jonathan Worthington <[EMAIL PROTECTED]> wrote: > Ovid wrote: > > By default, block parameters (including $_) are readonly, I hope that is a deep readonly? In other words, if $_.position returns an array reference, can I mutate a value in that reference and the state of $_ is thereby changed? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Google index and subsets (two topics for the price of one!)
Ovid wrote: Well, looking at the examples that you and Jonathan listed, I see I should refine my question. For example: subset Crosshair of Point where { $_.inside_of($target_area) || $target_area.has_moved ?? $_.move_inside($target_area) :: $target_area.move_outside($_) }; In other words, I think we could get proper constraint programming if a subset can mutate its variable. By default, block parameters (including $_) are readonly, but you can use the <-> pointy block syntax, which declares its parameters "is rw", or just do so explicitly. Here's one of the ways, and I think this would work (or at least is the correct syntax): subset Crosshair of Point where <-> $_ { $_.inside_of($target_area) || $target_area.has_moved ?? $_.move_inside($target_area) :: $target_area.move_outside($_) }; On the other hand, this could lead to mysterious action at a distance. The losses are significant, but the wins seem absolutely fascinating. Well, you are explicitly declaring the rw nature of the constraint right there in the signature, so it's easy enough to know that it might change things without having to look through the code inside the block to check. So I think it's not quite so spooky, or at least the spookiness is declared up front. :-) Jonathan
Re: Google index and subsets (two topics for the price of one!)
--- Moritz Lenz <[EMAIL PROTECTED]> wrote: > Ovid wrote: > > Anyone have any idea why Google is not indexing the official Perl 6 > > documentation at perlcabal.org/syn? I checked the robots.txt and > it > > looks fine: > > > > http://www.perlcabal.org/robots.txt > > > > But the search box on http://www.perlcabal.org/syn/ returns > nothing. > > The whole domain seems to be missing from the index, not only the > synopsis. > > If nobody else has any idea, I could get a webmaster account and try > to > find out what's wrong. > > > Specifically, I was looking for the documentation on how subsets > work > > as it looks like we can get declarative style constraint > programming > > for free: > > > > subset Crosshair of Point where { $_.inside_of($target_zone) }; > > > > Is that valid syntax? > > Yes. See http://perlcabal.org/syn/S02.html#Polymorphic_types for > similar > examples. Well, looking at the examples that you and Jonathan listed, I see I should refine my question. For example: subset Crosshair of Point where { $_.inside_of($target_area) || $target_area.has_moved ?? $_.move_inside($target_area) :: $target_area.move_outside($_) }; In other words, I think we could get proper constraint programming if a subset can mutate its variable. Otherwise, all assignment would need to be wrapped inside of an eval and the code would be more bug-prone. Will said mutating work? If it does, all logic handling constraints can be encapsulated in one spot. On the other hand, this could lead to mysterious action at a distance. The losses are significant, but the wins seem absolutely fascinating. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Google index and subsets (two topics for the price of one!)
Ovid wrote: Specifically, I was looking for the documentation on how subsets work See S12: http://dev.perl.org/perl6/doc/design/syn/S12.html#Types_and_Subtypes as it looks like we can get declarative style constraint programming for free: subset Crosshair of Point where { $_.inside_of($target_zone) }; Is that valid syntax? Yes. I presented some slides on it, under the name "dependant types", at the NPW recently. http://www.jnthn.net/papers/2008-npw-understanding-perl6-slides.pdf Aside: you can play with them in Rakudo somewhat, if you want to get a feel for them a bit more. You can declare them just fine with the syntax you wrote above; you can also declare anonymous ones on subroutine parameters too (and refer to other parameters inside them) and they will be enforced, plus they will be enforced on variables. Lexically scoping them and the "my Str Foo where ..." forms likely don't work just yet, though, and they don't yet act as tie-breakers in MMD. Hope this helps, Jonathan
Re: Google index and subsets (two topics for the price of one!)
Ovid wrote: > Anyone have any idea why Google is not indexing the official Perl 6 > documentation at perlcabal.org/syn? I checked the robots.txt and it > looks fine: > > http://www.perlcabal.org/robots.txt > > But the search box on http://www.perlcabal.org/syn/ returns nothing. The whole domain seems to be missing from the index, not only the synopsis. If nobody else has any idea, I could get a webmaster account and try to find out what's wrong. > Specifically, I was looking for the documentation on how subsets work > as it looks like we can get declarative style constraint programming > for free: > > subset Crosshair of Point where { $_.inside_of($target_zone) }; > > Is that valid syntax? Yes. See http://perlcabal.org/syn/S02.html#Polymorphic_types for similar examples. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/