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!)
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!)
--- 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!)
--- 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!)
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!)
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!)
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/
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!)
--- 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:
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!)
--- 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/
