Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-18 Thread Moritz Lenz
TSa wrote: > HaloO, > > Daniel Ruoso wrote: >> Em Ter, 2009-02-17 às 09:19 -0300, Daniel Ruoso escreveu: >>> multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {...} >> >> As masak++ and moritz++ pointed out, this should be written >> >> multi infix:<+> (int $i where 2, int $j where 2) {

Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-17 Thread Darren Duncan
Something that may possibly be relevant to this discussion as an object lesson ... In the near future, probably next week, I'm going to re-implement the guts of my Set::Relation module (for Perl 5, on CPAN now), from an eagerly evaluated sometimes mutable or immutable object, to a often-lazily

Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-17 Thread Martin D Kealey
On Tue, 17 Feb 2009, TSa wrote: > I fully agree that immutability is not a property of types in a signature. > But a signature should have a purity lock :(Int $i is pure) that snapshots > an object state [...] > Note that this purity lock doesn't lock the outer object. It is only > affecting the i

Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-17 Thread Darren Duncan
TSa wrote: Daniel Ruoso wrote: The problem is that you can't really know wether a value is immutable or not, we presume a literal 1 to be immutable, but even if you receive :(Int $i), it doesn't mean $i is immutable, because that signature only checks if $i ~~ Int, which actually results in $i.d

Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-17 Thread TSa
HaloO, Daniel Ruoso wrote: Em Ter, 2009-02-17 às 09:19 -0300, Daniel Ruoso escreveu: multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {...} As masak++ and moritz++ pointed out, this should be written multi infix:<+> (int $i where 2, int $j where 2) {...} Hmm, both these forms strik

Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-17 Thread TSa
HaloO, Daniel Ruoso wrote: The problem is that you can't really know wether a value is immutable or not, we presume a literal 1 to be immutable, but even if you receive :(Int $i), it doesn't mean $i is immutable, because that signature only checks if $i ~~ Int, which actually results in $i.does(

Re: Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-17 Thread Daniel Ruoso
Em Ter, 2009-02-17 às 09:19 -0300, Daniel Ruoso escreveu: > multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {...} As masak++ and moritz++ pointed out, this should be written multi infix:<+> (int $i where 2, int $j where 2) {...} daniel

Detecting side-effects in Perl 6 (Was: Re: infectious traits and pure functions)

2009-02-17 Thread Daniel Ruoso
Em Seg, 2009-02-16 às 21:21 -0800, Darren Duncan escreveu: > marking it as consisting of just immutable values, and in the > routines case marking it as having no side effects The problem is that you can't really know wether a value is immutable or not, we presume a literal 1 to be immutable, but

Re: infectious traits and pure functions

2009-02-17 Thread Darren Duncan
Jon Lang wrote: I'm not saying that it needs to decide whether or not you have a halting problem; I'm saying that if there's any possibility that you _might_ have one, you should stop looking. Let's take it as a given that things such as exceptions, threads, and co-routines make the automated es

Re: infectious traits and pure functions

2009-02-16 Thread Jon Lang
Martin D Kealey wrote: > On Mon, 16 Feb 2009, Jon Lang wrote: >> if there's any doubt about the matter (e.g., conclusively proving or >> disproving purity would be NP-complete or a halting problem), then > > Deciding whether you have a halting problem IS a halting problem... :-) You're making the

Re: infectious traits and pure functions

2009-02-16 Thread Martin Kealey
I wrote: > > In the general case, if your language has both pure and impure > > functions, proving (at compile time) that something is not impure is an > > NP-complete problem. On Mon, 16 Feb 2009, Mark Biggar wrote: > Worse it's equivalent to the halting problem (I.e., not solvable). Quite corre

Re: infectious traits and pure functions

2009-02-16 Thread Martin D Kealey
On Mon, 16 Feb 2009, Jon Lang wrote: > if there's any doubt about the matter (e.g., conclusively proving or > disproving purity would be NP-complete or a halting problem), then Deciding whether you have a halting problem IS a halting problem... :-) -Martin

Re: infectious traits and pure functions

2009-02-16 Thread Jon Lang
Darren Duncan wrote: > There are ways to get what you want if you're willing to trade for more > restrictiveness in the relevant contexts. > > If we have a way of marking types/values and routines somehow as being pure, > in the types case marking it as consisting of just immutable values, and in >

Re: infectious traits and pure functions

2009-02-16 Thread Darren Duncan
Mark Biggar wrote: Martin D Kealey wrote: But if you have objects and nested functions, the exact inference rule gets a whole lot more complicated. With exceptions, threads and co-routines it's a nightmare. In the general case, if your language has both pure and impure functions, proving (at c

Re: infectious traits and pure functions

2009-02-16 Thread Mark Biggar
Martin D Kealey wrote: But if you have objects and nested functions, the exact inference rule gets a whole lot more complicated. With exceptions, threads and co-routines it's a nightmare. In the general case, if your language has both pure and impure functions, proving (at compile time) that some

Re: infectious traits and pure functions

2009-02-16 Thread Martin D Kealey
On Fri, 13 Feb 2009, Jon Lang wrote: > In reading about functional programming, I ran across the concept of > the "pure function" - i.e., a function that doesn't produce side > effects. [...] > It occurred to me that this business of marking functions as pure could be > done in perl by means of tra

infectious traits and pure functions

2009-02-13 Thread Jon Lang
In reading over the Debugging draft (i.e., the future S20), I ran across the concept of the infectious trait - that is, a trait that doesn't just get applied to the thing to which it is explicitly applied; rather, it tends to spread to whatever else that thing comes in contact with. "Taint" is the