On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote:
On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes j...@n-brain.net
wrote:
You must think I'm arguing for some kind of low-level analog of C,
augmented with an effect system. I'm not. You can't do that.
No, I don't. I think you're arguing
On Sun, Aug 16, 2009 at 2:50 PM, John A. De Goes j...@n-brain.net wrote:
On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote:
On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes j...@n-brain.net
wrote:
You must think I'm arguing for some kind of low-level analog of C,
augmented with an
On Aug 15, 2009, at 2:55 PM, John A. De Goes wrote:
If you don't like the file system, consider mutable memory. An
effect system will tell me I can safely update two pieces of non-
overlapping, contiguous memory concurrently, even in different
threads if the complexity so justifies it. The
In the presence of _uncontrolled concurrency_, you are correct, but
uncontrolled concurrency is a failed paradigm littered with defective
software.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 16, 2009, at
2009/08/14 John A. De Goes j...@n-brain.net:
Hmmm, my point (perhaps I wasn't clear), is that different
effects have different commutability properties. In the case
of a file system, you can commute two sequential reads from
two different files.
I think this is a bad example -- it's not
On Aug 14, 2009, at 9:07 PM, Sebastian Sylvan wrote:
That's a separate issue. The problem is that if you *do* depend on
outside interference, then the sequence of operations matters.
You're example is highly contrived. Were I designing an effect system,
I would not design for programs that
On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote:
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes j...@n-brain.net
wrote:
If you don't like the file system, consider mutable memory. An
effect system will tell me I can safely update two pieces of non-
overlapping, contiguous memory
On Sat, Aug 15, 2009 at 11:54 PM, John A. De Goes j...@n-brain.net wrote:
On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote:
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes j...@n-brain.net wrote:
If you don't like the file system, consider mutable memory. An effect
system will tell me I
On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote:
2009/08/14 John A. De Goes j...@n-brain.net:
Hmmm, my point (perhaps I wasn't clear), is that different
effects have different commutability properties. In the case
of a file system, you can commute two sequential reads from
two different files.
On Sat, Aug 15, 2009 at 11:45 PM, John A. De Goes j...@n-brain.net wrote:
Effect system optimizations are about taking programs that are correct, and
transforming them to faster but equivalent programs that are still correct.
And since reordering access to externally modifiable data (external
On Aug 15, 2009, at 4:59 PM, Sebastian Sylvan wrote:
Your point about safety in C has no relation to safety in a
functional language with a sophisticated effect system.
I'm sorry, but I think it does. You're advocating that modifications
to mutable state shouldn't have sequential
On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes j...@n-brain.net wrote:
On Aug 15, 2009, at 4:59 PM, Sebastian Sylvan wrote:
Your point about safety in C has no relation to safety in a functional
language with a sophisticated effect system.
I'm sorry, but I think it does. You're
Hmmm, my point (perhaps I wasn't clear), is that different effects
have different commutability properties. In the case of a file system,
you can commute two sequential reads from two different files. This
has no effect on the result of the computation, assuming no
interference from
On Fri, Aug 14, 2009 at 1:41 PM, John A. De Goes j...@n-brain.net wrote:
Hmmm, my point (perhaps I wasn't clear), is that different effects have
different commutability properties. In the case of a file system, you can
commute two sequential reads from two different files. This has no effect
I think version is control is really just a subset of a larger effect
theory. E.g. I've been experimenting with a parallel undo/redo system
in C#, where some actions can commute and be undone separately, and
for detecting this, the actions need to explicitly expose what they
will change; so this
My intuition says the proper formalism is that undo is left adjoint to redo.
They together form a monad in the category of redoable actions. return
lifts doable actions to undoable ones by attaching an empty undo stack.
join lowers (reflects) a first-class undoable action out of the undo
On Fri, Aug 14, 2009 at 9:41 PM, John A. De Goes j...@n-brain.net wrote:
Hmmm, my point (perhaps I wasn't clear), is that different effects have
different commutability properties. In the case of a file system, you can
commute two sequential reads from two different files.
But you can't! I
On Aug 14, 2009, at 8:21 PM, Sebastian Sylvan wrote:
But you can't! I can easily envisage a scenario where there's a link
between two pieces of data in two different files, where it's okay
if the data in file A is newer (in a versioning sense, not a
timestamp sense) than the corresponding
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes j...@n-brain.net wrote:
On Aug 14, 2009, at 8:21 PM, Sebastian Sylvan wrote:
But you can't! I can easily envisage a scenario where there's a link
between two pieces of data in two different files, where it's okay if the
data in file A is
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes j...@n-brain.net wrote:
If you don't like the file system, consider mutable memory. An effect
system will tell me I can safely update two pieces of non-overlapping,
contiguous memory concurrently, even in different threads if the complexity
so
On Thu, Aug 13, 2009 at 4:56 AM, John A. De Goes j...@n-brain.net wrote:
The next step is to distinguish between reading file A and reading file B,
between reading file A and writing file A, between reading one part of file
A and writing another part of file A, etc. When the effect system can
Hi Dan
On 12 Aug 2009, at 22:28, Dan Doel wrote:
On Wednesday 12 August 2009 10:12:14 am John A. De Goes wrote:
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.
It's
2009/08/12 John A. De Goes j...@n-brain.net:
The next step is to distinguish between reading file A and
reading file B, between reading file A and writing file A,
between reading one part of file A and writing another part of
file A, etc. When the effect system can carry that kind of
Another issue in DCC is in the course of writing a procedure, is that either
the programmer has too much information (the list of effects of all the
called procedures if they are explicit), or too little, if they are
generated and managed by the compiler.
How he knows for sure that a variable to
What if you have another program, written in C or something, that
monitors a file for changes, and if so changes the contents of
another file? Surely to catch that you must mark *all* file system
access as interefering? Even worse, another program could monitor
the state of a file and
Hmmm, bad example. Assume memory instead. That said, reordering/
parallelization of *certain combinations of* writes/reads to
independent files under whole program analysis is no less safe than
sequential writes/reads. It just feels less safe, but the one thing
that will screw both up is
On Aug 13, 2009, at 4:09 AM, Alberto G. Corona wrote:
Maybe, in Haskell, the coarse IO monad can be divided in smaller
monads as well
I don't even want to imagine how that would obfuscate otherwise
straightforward looking monadic code.
The root problem is that monads don't capture
John A. De Goes j...@n-brain.net sed:
Hmmm, bad example. Assume memory instead. That said, reordering/
parallelization of *certain combinations of* writes/reads to
independent files under whole program analysis is no less safe than
sequential writes/reads. It just feels less safe, but the one
On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes j...@n-brain.net wrote:
What if you have another program, written in C or something, that
monitors a file for changes, and if so changes the contents of another file?
Surely to catch that you must mark *all* file system access as
interefering?
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
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
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
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
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
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
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
On Wed, 12 Aug 2009 11:37:02 +0200
Peter Verswyvelen bugf...@gmail.com 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
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:
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
On Tue, Aug 11, 2009 at 3:51 PM, Robin Greengree...@greenrd.org wrote:
On Wed, 12 Aug 2009 11:37:02 +0200
Peter Verswyvelen bugf...@gmail.com 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:
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
On Wed, Aug 12, 2009 at 6:34 AM, Derek Elkins derek.a.elk...@gmail.comwrote:
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
On Wed, 12 Aug 2009 08:34:28 -0500
Derek Elkins derek.a.elk...@gmail.com wrote:
On Tue, Aug 11, 2009 at 3:51 PM, Robin Greengree...@greenrd.org
wrote:
On Wed, 12 Aug 2009 11:37:02 +0200
Peter Verswyvelen bugf...@gmail.com wrote:
Yes, sorry.
But I think I already found the answer to
On Wed, Aug 12, 2009 at 9:34 AM, Derek Elkinsderek.a.elk...@gmail.com wrote:
On Tue, Aug 11, 2009 at 3:51 PM, Robin Greengree...@greenrd.org wrote:
On Wed, 12 Aug 2009 11:37:02 +0200
Peter Verswyvelen bugf...@gmail.com wrote:
Yes, sorry.
But I think I already found the answer to my own
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
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)
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
On Wednesday 12 August 2009 10:12:14 am John A. De Goes wrote:
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.
It's definitely an interesting direction (possibly even the
2009/08/12 Dan Doel dan.d...@gmail.com:
On Wednesday 12 August 2009 10:12:14 am John A. De Goes wrote:
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.
It's
So what, because effect systems might not eliminate *all* boilerplate,
you'd rather use boilerplate 100% of the time? :-)
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 12, 2009, at 3:28 PM, Dan Doel wrote:
On Wednesday 12 August 2009 9:27:30 pm John A. De Goes wrote:
So what, because effect systems might not eliminate *all* boilerplate,
you'd rather use boilerplate 100% of the time? :-)
For most of my Haskell programs, the majority of the program is not made up of
straight IO or ST functions, so
Derek Elkins wrote:
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
Dan Doel wrote:
For instance: what effects does disciple support? Mutation and IO?
You can create your own top-level effects which interfere
will all others, for example:
effect !Network;
effect !File;
readFile :: String -(!e) String
:- !e = !File
Now any function that calls readFile
Dan Doel wrote:
Off hand, I'd say I don't write foo and fooM versions of functions much in
actual programs, either. Such duplication goes into libraries...
It would be ok if the duplication /was/ actually in the libraries,
but often it's not.
Note the lack of Data.Map.mapM and Data.Map.foldM.
Fair enough, but keep in mind an effect system does more than just
eliminate boilerplate: it provides richer information on the precise
nature of the interaction of a function with the real world. With the
right insight, you can reorder and parallelize all kinds of effectful
The next step is to distinguish between reading file A and reading
file B, between reading file A and writing file A, between reading one
part of file A and writing another part of file A, etc. When the
effect system can carry that kind of information, and not just for
files, but
On Wednesday 12 August 2009 11:46:29 pm Ben Lippmeier wrote:
Dan Doel wrote:
Off hand, I'd say I don't write foo and fooM versions of functions much
in actual programs, either. Such duplication goes into libraries...
It would be ok if the duplication /was/ actually in the libraries,
but
Dan Doel wrote:
On Wednesday 12 August 2009 11:46:29 pm Ben Lippmeier wrote:
Dan Doel wrote:
Off hand, I'd say I don't write foo and fooM versions of functions much
in actual programs, either. Such duplication goes into libraries...
It would be ok if the duplication /was/
On Aug 12, 2009, at 23:46 , Ben Lippmeier wrote:
Dan Doel wrote:
Off hand, I'd say I don't write foo and fooM versions of functions
much in actual programs, either. Such duplication goes into
libraries...
Note the lack of Data.Map.mapM and Data.Map.foldM. Want to apply a
monadic
59 matches
Mail list logo
