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) {...}
Hmm, both
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
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
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
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 strike
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
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 inner
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
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 traits
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
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
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
the
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
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 correct, my
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
15 matches
Mail list logo
