DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Peter Verswyvelen-2
I knew about DDC for a while but never bothered to look at it deeply
since it was so young, and at first sight it just did what ML did
(silently allowing side effects).

But when looking again at it, it seems it actually does some very
clever things to allow side effects and still be safe, a bit what one
does explicitly with Haskell's ST and IO monads, but in DDC, the
compiler seems to analyze where side effects happen and automatically
annotates/enrich the types (with things like region, closure and
effect information) to indicate this. The example given by DDC is that
in Haskell, you need two versions of each higher order function if you
really want your library to be reuseable, e.g. you need map and mapM,
but in DDC you just need one function, map, which also is written in a
pure style. See e.g.
http://www.haskell.org/haskellwiki/DDC/EffectSystem

I kind of agree with the DDC authors here; in Haskell as soon as a
function has a side effect, and you want to pass that function to a
pure higher order function, you're stuck, you need to pick the monadic
version of the higher order function, if it exists. So Haskell doesn't
really solve the modularity problem, you need two versions of each
higher order function really, and you need to carefully plan ahead of
time if you want to write in a monadic or pure style, and it also
splits my brain mentally ("side effects are ***evil***. But hang on,
how can I e.g. do a depth first search efficiently purely functional?
Damn, it seems I can't! Let's switch back to C#/C++!!! Nooooo ;-) This
seems to make Haskell not a good language for doing things like
extreme programming where code evolves, unless you have some insanely
clever refactoring tool ready that can convert pure into monadic
functions and vice versa.

Is it true that - as in DDC - side effects can be analyzed by the
compiler (in the same sense that say, strictness is analyzed), freeing
the library and user from writing/picking monadic versions??? If so,
would this indeed solve the modularity/reusablity issue? I feel you
can't have your cake and eat it here, so there must be catch? :-)

Thanks for sharing any thoughts on this,
Peter Verswyvelen
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Pavel Perikov
> unless you have some insanely
> clever refactoring tool ready that can convert pure into monadic
> functions and vice versa.

Not trying to attack the idea, just some thoughts:

I don't see much problem converting pure function into an "effectfull"  
form :) Having pure function
myPureFunction::a1->a2->a3->res
....
myPureFunction a1 a2 a3 -- pure call
myPureFunction <$> a1 <*> a2 <*> a3 -- call using Applicative

Probably, introducing some conventions and using some language  
extensions you can write a function taking pure function and  
converting it into monadic version (a-la SPJ' work on polyvariadic  
composition etc [1])

Have monadic function but needs to call it from pure code? use  
Control.Monad.Identity.

Not a big deal to me but maybe I'm missing the point

-----
[1] http://okmij.org/ftp/Haskell/types.html#polyvar-comp



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: DDC compiler and effects;better than Haskell?

Bayley, Alistair-3
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Pavel Perikov
>
> > unless you have some insanely
> > clever refactoring tool ready that can convert pure into monadic
> > functions and vice versa.
>
> Not trying to attack the idea, just some thoughts:
>
> I don't see much problem converting pure function into an
> "effectfull"  
> form :) Having pure function
> myPureFunction::a1->a2->a3->res
> ....
> myPureFunction a1 a2 a3 -- pure call
> myPureFunction <$> a1 <*> a2 <*> a3 -- call using Applicative
>
> Probably, introducing some conventions and using some language  
> extensions you can write a function taking pure function and  
> converting it into monadic version (a-la SPJ' work on polyvariadic  
> composition etc [1])
>
> Have monadic function but needs to call it from pure code? use  
> Control.Monad.Identity.
>
> Not a big deal to me but maybe I'm missing the point


In the HaRe catalogue (
http://www.cs.kent.ac.uk/projects/refactor-fp/catalogue/ ) there exists
a "Monadification" refactoring:
 
http://www.cs.kent.ac.uk/projects/refactor-fp/catalogue/Monadification1.
html

Alistair
*****************************************************************
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*****************************************************************

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Peter Verswyvelen-2
In reply to this post by Pavel Perikov
Well, the point is that you still have monadic and pure programming
styles. It's true that applicative style programming can help here,
but then you have these <$> and <*> operators everywhere, which also
feels like boilerplate code (as you mention, some extensions could
help here)

Monadic style even has the do syntax, which really looks imperative,
while of course, it isn't.

I know that for e.g. doing a DFS I can use the ST monad and still be
pure, however, my code *looks* imperative when I use the do syntax,
which mentally feels weird (maybe it's just me being mentally ill ;-)

It's even worse with the arrows syntax: without it I wouldn't be able
to write complex Yampa stuff, but the syntax makes me feels that I'm
drawing boxes and links using ASCII, and suddenly it *feels* different
than when doing "nice" pure / applicative style programming. Again,
maybe it's just my brain that is fucked up by 25 years of imperative
programming :)

So to me, keeping the syntax in a pure style (a bit like ML and F#)
plays nicer with my brain.

On Wed, Aug 12, 2009 at 11:13 AM, Pavel Perikov<[hidden email]> wrote:

>> unless you have some insanely
>> clever refactoring tool ready that can convert pure into monadic
>> functions and vice versa.
>
> Not trying to attack the idea, just some thoughts:
>
> I don't see much problem converting pure function into an "effectfull" form
> :) Having pure function
> myPureFunction::a1->a2->a3->res
> ....
> myPureFunction a1 a2 a3 -- pure call
> myPureFunction <$> a1 <*> a2 <*> a3 -- call using Applicative
>
> Probably, introducing some conventions and using some language extensions
> you can write a function taking pure function and converting it into monadic
> version (a-la SPJ' work on polyvariadic composition etc [1])
>
> Have monadic function but needs to call it from pure code? use
> Control.Monad.Identity.
>
> Not a big deal to me but maybe I'm missing the point
>
> -----
> [1] http://okmij.org/ftp/Haskell/types.html#polyvar-comp
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Bulat Ziganshin-2
In reply to this post by Pavel Perikov
Hello Pavel,

Wednesday, August 12, 2009, 1:13:31 PM, you wrote:

> Have monadic function but needs to call it from pure code? use
> Control.Monad.Identity.

by monadic function he probably meant ST or IO one, not polymorphic by
any monad

--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Pavel Perikov
In reply to this post by Peter Verswyvelen-2

On 12.08.2009, at 13:27, Peter Verswyvelen wrote:

> Well, the point is that you still have monadic and pure programming
> styles. It's true that applicative style programming can help here,
> but then you have these <$> and <*> operators everywhere, which also
> feels like boilerplate code (as you mention, some extensions could
> help here)

And you have higher-order functions, you're right. My reply was a bit  
rushed ;)

P.






>
> Monadic style even has the do syntax, which really looks imperative,
> while of course, it isn't.
>
> I know that for e.g. doing a DFS I can use the ST monad and still be
> pure, however, my code *looks* imperative when I use the do syntax,
> which mentally feels weird (maybe it's just me being mentally ill ;-)
>
> It's even worse with the arrows syntax: without it I wouldn't be able
> to write complex Yampa stuff, but the syntax makes me feels that I'm
> drawing boxes and links using ASCII, and suddenly it *feels* different
> than when doing "nice" pure / applicative style programming. Again,
> maybe it's just my brain that is fucked up by 25 years of imperative
> programming :)
>
> So to me, keeping the syntax in a pure style (a bit like ML and F#)
> plays nicer with my brain.
>
> On Wed, Aug 12, 2009 at 11:13 AM, Pavel Perikov<[hidden email]>  
> wrote:
>>> unless you have some insanely
>>> clever refactoring tool ready that can convert pure into monadic
>>> functions and vice versa.
>>
>> Not trying to attack the idea, just some thoughts:
>>
>> I don't see much problem converting pure function into an  
>> "effectfull" form
>> :) Having pure function
>> myPureFunction::a1->a2->a3->res
>> ....
>> myPureFunction a1 a2 a3 -- pure call
>> myPureFunction <$> a1 <*> a2 <*> a3 -- call using Applicative
>>
>> Probably, introducing some conventions and using some language  
>> extensions
>> you can write a function taking pure function and converting it  
>> into monadic
>> version (a-la SPJ' work on polyvariadic composition etc [1])
>>
>> Have monadic function but needs to call it from pure code? use
>> Control.Monad.Identity.
>>
>> Not a big deal to me but maybe I'm missing the point
>>
>> -----
>> [1] http://okmij.org/ftp/Haskell/types.html#polyvar-comp
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: RE: DDC compiler and effects;better than Haskell?

Peter Verswyvelen-2
In reply to this post by Bayley, Alistair-3
Yes, but HaRe *is* extremely clever :-)

I just wish I could use it, but since it doesn't support many GHC
extensions, I haven't.

On Wed, Aug 12, 2009 at 11:26 AM, Bayley,
Alistair<[hidden email]> wrote:

>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Pavel Perikov
>>
>> > unless you have some insanely
>> > clever refactoring tool ready that can convert pure into monadic
>> > functions and vice versa.
>>
>> Not trying to attack the idea, just some thoughts:
>>
>> I don't see much problem converting pure function into an
>> "effectfull"
>> form :) Having pure function
>> myPureFunction::a1->a2->a3->res
>> ....
>> myPureFunction a1 a2 a3 -- pure call
>> myPureFunction <$> a1 <*> a2 <*> a3 -- call using Applicative
>>
>> Probably, introducing some conventions and using some language
>> extensions you can write a function taking pure function and
>> converting it into monadic version (a-la SPJ' work on polyvariadic
>> composition etc [1])
>>
>> Have monadic function but needs to call it from pure code? use
>> Control.Monad.Identity.
>>
>> Not a big deal to me but maybe I'm missing the point
>
>
> In the HaRe catalogue (
> http://www.cs.kent.ac.uk/projects/refactor-fp/catalogue/ ) there exists
> a "Monadification" refactoring:
>
> http://www.cs.kent.ac.uk/projects/refactor-fp/catalogue/Monadification1.
> html
>
> Alistair
> *****************************************************************
> Confidentiality Note: The information contained in this message,
> and any attachments, may contain confidential and/or privileged
> material. It is intended solely for the person(s) or entity to
> which it is addressed. Any review, retransmission, dissemination,
> or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient(s) is
> prohibited. If you received this in error, please contact the
> sender and delete the material from any computer.
> *****************************************************************
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Peter Verswyvelen-2
In reply to this post by Bulat Ziganshin-2
Yes, sorry.

But I think I already found the answer to my own question.

DDC functions that are lazy don't allow side effects:
http://www.haskell.org/haskellwiki/DDC/EvaluationOrder

Anyway it would be cool if the DDC EffectSystem would also work on
lazy functions :)

On Wed, Aug 12, 2009 at 11:28 AM, Bulat
Ziganshin<[hidden email]> wrote:

> Hello Pavel,
>
> Wednesday, August 12, 2009, 1:13:31 PM, you wrote:
>
>> Have monadic function but needs to call it from pure code? use
>> Control.Monad.Identity.
>
> by monadic function he probably meant ST or IO one, not polymorphic by
> any monad
>
> --
> Best regards,
>  Bulat                            mailto:[hidden email]
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

greenrd
On Wed, 12 Aug 2009 11:37:02 +0200
Peter Verswyvelen <[hidden email]> wrote:

> Yes, sorry.
>
> But I think I already found the answer to my own question.
>
> DDC functions that are lazy don't allow side effects:
> http://www.haskell.org/haskellwiki/DDC/EvaluationOrder
>
> Anyway it would be cool if the DDC EffectSystem would also work on
> lazy functions :)

As was just pointed out in the unsafeDestructiveAssign thread from which
this thread was forked, effects are incompatible with non-strict
evaluation. The compiler is supposed to be able to reorder non-strict
evaluation to do optimisations, but that can't be done if effects
could happen. Also, effects would destroy modular reasoning.
--
Robin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Jules Bean
In reply to this post by Peter Verswyvelen-2
Peter Verswyvelen wrote:
> I kind of agree with the DDC authors here; in Haskell as soon as a
> function has a side effect, and you want to pass that function to a
> pure higher order function, you're stuck, you need to pick the monadic
> version of the higher order function, if it exists.

I just want to point out that you could *always* use the monadic version.

That is, mapM subsumes map. Just use the Identity monad if you don't
have anything really monadic going on.

The reason we don't is that that looks + feels ugly.

Jules

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Peter Verswyvelen-2
In reply to this post by greenrd
Is this really the case? Or is just hard to implement?

I mean, if...then...else is always kind of lazy in it's 2nd and 3rd
argument, but I think DDC handles this correctly even with the
presence of side effects (not sure, but it has a little presentation
about it: http://cs.anu.edu.au/people/Ben.Lippmeier/talks/poisoning-20090618.pdf)

And it's still possible to reason about a function with side effects
in DDC since the side effects are visible in the type signature (you
might need a good editor that shows you the inferred signatures, as
done with F#). I mean it's possible to reason about monadic ST or IO
no? I agree it's hard to reason about code that is not honest about
side effects in its type signature.

So couldn't this be generalized? If might completely miss the point
here since I'm not at all academic, I'm an old school imperative
hacker.








On Tue, Aug 11, 2009 at 10:51 PM, Robin Green<[hidden email]> wrote:

> As was just pointed out in the unsafeDestructiveAssign thread from which
> this thread was forked, effects are incompatible with non-strict
> evaluation. The compiler is supposed to be able to reorder non-strict
> evaluation to do optimisations, but that can't be done if effects
> could happen. Also, effects would destroy modular reasoning.
> --
> Robin
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Tom Davies-6

On 12/08/2009, at 9:09 PM, Peter Verswyvelen wrote:

> Is this really the case? Or is just hard to implement?
>
> I mean, if...then...else is always kind of lazy in it's 2nd and 3rd
> argument, but I think DDC handles this correctly even with the
> presence of side effects (not sure, but it has a little presentation
> about it: http://cs.anu.edu.au/people/Ben.Lippmeier/talks/poisoning-20090618.pdf)
>

As I haven't seen it mentioned on this thread: Ben Lippmeier's PhD  
thesis is available:
http://cs.anu.edu.au/~Ben.Lippmeier/project/thesis/thesis-lippmeier-sub.pdf

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Derek Elkins
In reply to this post by greenrd
On Tue, Aug 11, 2009 at 3:51 PM, Robin Green<[hidden email]> wrote:

> On Wed, 12 Aug 2009 11:37:02 +0200
> Peter Verswyvelen <[hidden email]> wrote:
>
>> Yes, sorry.
>>
>> But I think I already found the answer to my own question.
>>
>> DDC functions that are lazy don't allow side effects:
>> http://www.haskell.org/haskellwiki/DDC/EvaluationOrder
>>
>> Anyway it would be cool if the DDC EffectSystem would also work on
>> lazy functions :)
>
> As was just pointed out in the unsafeDestructiveAssign thread from which
> this thread was forked, effects are incompatible with non-strict
> evaluation.

No, they aren't.  At least, they aren't in any technical way.  There
have been more than a few languages supporting both laziness and
mutation starting with Algol.

> The compiler is supposed to be able to reorder non-strict
> evaluation to do optimisations, but that can't be done if effects
> could happen.

There's nothing special about non-strict evaluation that makes the
antecedent true.  Replacing "non-strict" with "strict" gives just as
much of a valid statement.  It is purity that allows (some) reordering
of evaluation.

> Also, effects would destroy modular reasoning.

Again, it is purity, not laziness, that allows compositional
reasoning.  Effects destroy compositional reasoning in a strict
language just as much.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

greenrd
On Wed, 12 Aug 2009 08:34:28 -0500
Derek Elkins <[hidden email]> wrote:

> On Tue, Aug 11, 2009 at 3:51 PM, Robin Green<[hidden email]>
> wrote:
> > On Wed, 12 Aug 2009 11:37:02 +0200
> > Peter Verswyvelen <[hidden email]> wrote:
> >
> >> Yes, sorry.
> >>
> >> But I think I already found the answer to my own question.
> >>
> >> DDC functions that are lazy don't allow side effects:
> >> http://www.haskell.org/haskellwiki/DDC/EvaluationOrder
> >>
> >> Anyway it would be cool if the DDC EffectSystem would also work on
> >> lazy functions :)
> >
> > As was just pointed out in the unsafeDestructiveAssign thread from
> > which this thread was forked, effects are incompatible with
> > non-strict evaluation.
>
> No, they aren't.  At least, they aren't in any technical way.  There
> have been more than a few languages supporting both laziness and
> mutation starting with Algol.

OK, explicitly creating thunks, like in Algol, LISP and CAL, can work,
because you can either prevent the programmer from using mutation
inside a thunk (as in the CAL approach), or rely on the programmer to
ensure that mutations are only done in a safe order (as in the
"callback as thunk" approach, which can be done in almost any impure
language).

But if almost *every* expression is a thunk, as in a non-strict
language like Haskell, and if moreover evaluation order can differ
depending on the compiler/interpreter, or compiler version, or compiler
flags, it becomes impractical to combine them. So yes, I agree, it's
not an absolute technical incompatibility, it's a practical one.

> > Also, effects would destroy modular reasoning.
>
> Again, it is purity, not laziness, that allows compositional
> reasoning.  Effects destroy compositional reasoning in a strict
> language just as much.

Not really - in a strict language, if in method M action A always
happens before action B, then that fact will remain true in whichever
context M is called (ignoring threading issues). In a non-strict, impure
language, assuming monads are not used, if you have a function f which
performs actions A and B, and two other functions g and h which both
call f, the actions could happen in one order in g, and in the opposite
order - or not at all - in h, because of a difference in data demanded
by each function. Indeed, unless g and h are "top-level" functions (in
the sense that they are main functions or invoked from some
ghci-equivalent) the notion of "the" order the actions are performed in
is ill-defined, because it could vary depending on which function g or
h is being called from.

Now, you could say, the strict order of evaluation can be simulated in
a non-strict language on a case-by-case basis by using monads or
whatever. Well, yes, but that would be missing the point, because the
original point of this discussion was to avoid having to use monads.
--
Robin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

John A. De Goes
In reply to this post by Derek Elkins
On Aug 12, 2009, at 7:34 AM, Derek Elkins wrote:

> Again, it is purity, not laziness, that allows compositional
> reasoning.  Effects destroy compositional reasoning in a strict
> language just as much.


Yes, but that's just as much true in the IO monad as in effectful code  
in DDC. I think the point is that a functional language with a built-
in effect system that captures the nature of effects is pretty damn  
cool and eliminates a lot of boilerplate.

Regards,

John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration

http://www.n-brain.net    |    877-376-2724 x 101

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Jason Dagit-2
In reply to this post by Derek Elkins


On Wed, Aug 12, 2009 at 6:34 AM, Derek Elkins <[hidden email]> wrote:

Again, it is purity, not laziness, that allows compositional
reasoning.  Effects destroy compositional reasoning in a strict
language just as much.

Totality also matters, but for some reason we take that for granted :)

Jason

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

David Menendez-2
In reply to this post by Derek Elkins
On Wed, Aug 12, 2009 at 9:34 AM, Derek Elkins<[hidden email]> wrote:

> On Tue, Aug 11, 2009 at 3:51 PM, Robin Green<[hidden email]> wrote:
>> On Wed, 12 Aug 2009 11:37:02 +0200
>> Peter Verswyvelen <[hidden email]> wrote:
>>
>>> Yes, sorry.
>>>
>>> But I think I already found the answer to my own question.
>>>
>>> DDC functions that are lazy don't allow side effects:
>>> http://www.haskell.org/haskellwiki/DDC/EvaluationOrder
>>>
>>> Anyway it would be cool if the DDC EffectSystem would also work on
>>> lazy functions :)
>>
>> As was just pointed out in the unsafeDestructiveAssign thread from which
>> this thread was forked, effects are incompatible with non-strict
>> evaluation.
>
> No, they aren't.  At least, they aren't in any technical way.  There
> have been more than a few languages supporting both laziness and
> mutation starting with Algol.

As far as I know, Algol had call-by-name, not call-by-need.

--
Dave Menendez <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Felipe Lessa
In reply to this post by Derek Elkins
On Wed, Aug 12, 2009 at 08:34:28AM -0500, Derek Elkins wrote:
> > As was just pointed out in the unsafeDestructiveAssign thread from which
> > this thread was forked, effects are incompatible with non-strict
> > evaluation.
>
> No, they aren't.  At least, they aren't in any technical way.  There
> have been more than a few languages supporting both laziness and
> mutation starting with Algol.

But laziness is just one way of implementing non-strictness,
right?  What about others methods?

--
Felipe.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Don Stewart-2
In reply to this post by Peter Verswyvelen-2
bugfact:
> Well, the point is that you still have monadic and pure programming
> styles. It's true that applicative style programming can help here,
> but then you have these <$> and <*> operators everywhere, which also
> feels like boilerplate code (as you mention, some extensions could
> help here)

Overloading whitespace as application in the Identity idiom! :)

-- Do
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?)

Conor McBride-2

On 12 Aug 2009, at 20:40, Don Stewart wrote:

> bugfact:
>> Well, the point is that you still have monadic and pure programming
>> styles. It's true that applicative style programming can help here,
>> but then you have these <$> and <*> operators everywhere, which also
>> feels like boilerplate code (as you mention, some extensions could
>> help here)
>
> Overloading whitespace as application in the Identity idiom! :)

[cough!]

Conor

psst: http://personal.cis.strath.ac.uk/~conor/pub/she/idiom.html

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
1234