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) {
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
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
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
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
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(
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
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
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
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
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
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
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
>
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
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
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
16 matches
Mail list logo
