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
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 IO
On Sun, Aug 16, 2009 at 2:50 PM, John A. De Goes 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
> 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
On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote:
On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes
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 for making access
On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes 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 advocating tha
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 semantic
On Sat, Aug 15, 2009 at 11:45 PM, John A. De Goes 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 includes
memo
On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote:
2009/08/14 John A. De Goes :
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
On Sat, Aug 15, 2009 at 11:54 PM, John A. De Goes 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 wrote:
>>
>> If you don't like the file system, consider mutable memory. An effect
>> system will tell me I can safely update two p
On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote:
On Sat, Aug 15, 2009 at 3:55 AM, 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
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 tha
2009/08/14 John A. De Goes :
> 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 something that's
On Sat, Aug 15, 2009 at 3:55 AM, 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
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes 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 "newer" (in a
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 Fri, Aug 14, 2009 at 9:41 PM, John A. De Goes 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 can easily e
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
stack
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 al
On Fri, Aug 14, 2009 at 1:41 PM, John A. De Goes 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 on
> the resu
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 other
On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes 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"? Even worse,
"John A. De Goes" 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 thing
>
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 enou
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
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 con
Job Vranish wrote:
Does anybody know if there is some unsafe IO function that would let me do
destructive assignment?
Something like:
a = 5
main = do
veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign a 8
print a
8
Untested, just guessing:
{-# NOILINE aRef , a #-}
aRe
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 b
2009/08/12 John A. De Goes :
> 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
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 def
On Thu, Aug 13, 2009 at 4:56 AM, John A. De Goes 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 carry
> that
On Wed, Aug 12, 2009 at 06:48:33PM +0100, John Lato wrote:
> On Wed, Aug 12, 2009 at 2:39 PM, Derek Elkins wrote:
> >
> > (To Alberto as well.)
> >
> > Unsurprisingly, Lennart stated the real issue, but I'll re-emphasize
> > it. As much trouble as such a profound violation of purity would
> > caus
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
computati
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/ actual
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,
>
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 network,
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
computations.
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. W
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
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
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, 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:
O
2009/08/12 Dan Doel :
> 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 inter
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 t
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
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 her
On Wed, Aug 12, 2009 at 2:39 PM, Derek Elkins wrote:
>
> (To Alberto as well.)
>
> Unsurprisingly, Lennart stated the real issue, but I'll re-emphasize
> it. As much trouble as such a profound violation of purity would
> cause, it's not the biggest problem. If that were all, you could
> easily wr
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
>
On Wed, Aug 12, 2009 at 9:34 AM, Derek Elkins wrote:
> On Tue, Aug 11, 2009 at 3:51 PM, Robin Green wrote:
>> On Wed, 12 Aug 2009 11:37:02 +0200
>> Peter Verswyvelen wrote:
>>
>>> Yes, sorry.
>>>
>>> But I think I already found the answer to my own question.
>>>
>>> DDC functions that are lazy don
Yeah I'm thinking that even if I had such a function, it might be impossible
to make it play nicely. I think I can do a restricted form of what I want
with STRefs and StableNames (still dangerous) so I think I'll stick with
that at least while experimenting in haskell.
DCC looks extremely interest
On Wed, 12 Aug 2009 08:34:28 -0500
Derek Elkins wrote:
> On Tue, Aug 11, 2009 at 3:51 PM, Robin Green
> wrote:
> > On Wed, 12 Aug 2009 11:37:02 +0200
> > Peter Verswyvelen wrote:
> >
> >> Yes, sorry.
> >>
> >> But I think I already found the answer to my own question.
> >>
> >> DDC functions tha
On Wed, Aug 12, 2009 at 6: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.
Totality also matters, but for some reason we take that for granted :)
Jason
_
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 poi
me between different compiler
> versions, changed by compiler flags and phases of the moon, etc. I
> have an example in a darcs repo somewhere...
>
> Cheers,
> John
>
>> From: Job Vranish
>> Subject: Re: [Haskell-cafe] unsafeDestructiveAssign?
>>
>> Ga!
On Tue, Aug 11, 2009 at 3:51 PM, Robin Green wrote:
> On Wed, 12 Aug 2009 11:37:02 +0200
> Peter Verswyvelen 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/DD
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
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.
On Wed, 12 Aug 2009 11:37:02 +0200
Peter Verswyvelen 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 Eff
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
would be difficult to
> predict in advance, probably not the same between different compiler
> versions, changed by compiler flags and phases of the moon, etc. I
> have an example in a darcs repo somewhere...
>
> Cheers,
> John
>
> > From: Job Vranish
> > Subject: Re: [Has
Cheers,
John
> From: Job Vranish
> Subject: Re: [Haskell-cafe] unsafeDestructiveAssign?
>
> Ga! Before to many people start flooding me responses of "This is really
> dumb idea don't do it!" I would like to clarify that for the most part
> IKnowWhatI'mDoing(TM)
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
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,
Bulatmailto:
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 ment
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 e
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->
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 wh
2009/8/12 Job Vranish :
> Does anybody know if there is some unsafe IO function that would let me do
> destructive assignment?
> Something like:
>
> a = 5
> main = do
> veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign a 8
> print a
>> 8
I doubt you will be able to achieve tha
No, there's no way you can change the value of 'a' after the fact.
Since 'a' is a constant the compiler has most likely inlined it
wherever it has been used, the done constant folding etc.
If you need an updateable variable, you need to tell the compiler,
otherwise it will assume your code is pure.
Opps, didn't "reply to all"
I hate it when that happens...
On Tue, Aug 11, 2009 at 1:00 PM, Job Vranish wrote:
> haha, yeah.
>
> What I'm actually trying to do is make a way to manipulate arbitrary
> recursive algebraic data structures as if they were graphs (not for
> performance reasons but be
Job Vranish wrote:
What I am trying to do is hyper unusual and I really do need an
unsafeHorribleThings to do it.
Normally when I really, honestly think this, I'm wrong anyway.
- Jake
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.
Job Vranish writes:
> I am well aware of the usual ST/IORefs as the usual solutions to data
> mutability in haskell.
> I very very much understand purity, and why it is a good thing, and why we
> should try to stay away from IO and ST as much
> as possible.
> I am very much away that even if I
On Tue, Aug 11, 2009 at 12:45:29PM -0400, Job Vranish wrote:
> What I am trying to do is hyper unusual and I really do need an
> unsafeHorribleThings to do it.
I guess these unsafeHorribleThings are impossible, you're trying
to subvert the very core of the language. The only thing that
comes clos
Hello Job,
Tuesday, August 11, 2009, 7:48:45 PM, you wrote:
> I'm also looking for a way to make actual copies of data.
> so I could do something like this:
i think you are just going non-FP way. haskell is great for declaring
algorithms in pure mathematical way - as a function projecting input
Ga! Before to many people start flooding me responses of "This is really
dumb idea don't do it!" I would like to clarify that for the most part
IKnowWhatI'mDoing(TM)
I am well aware of the usual ST/IORefs as the usual solutions to data
mutability in haskell.
I very very much understand purity, and
Hello John,
Tuesday, August 11, 2009, 8:23:26 PM, you wrote:
> I can see how something like this would be useful to some areas. There
> are many cases (graphs!) where it's just easier to build up structures
> destructively, seal them, and return them to happyPureFunTimesLand.
it's ST monad. btw,
> unsafeHorribleThings
I think we have a name for this new feature.
I can see how something like this would be useful to some areas. There
are many cases (graphs!) where it's just easier to build up structures
destructively, seal them, and return them to happyPureFunTimesLand.
Even if GHC does d
Job Vranish writes:
> Does anybody know if there is some unsafe IO function that would let me do
> destructive assignment?
> Something like:
>
> a = 5
> main = do
> veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign a 8
> print a
>> 8
Aren't StateT or IORefs the exact thing
In both of your examples, a simple let would allow you to rebind the
name (not the same as assigning, but it didn't look like you need that
in those examples at least).
Note that you're already in IO, so you can use an IORef if you want a
true mutable variable, or an STRef in another function if y
Does anybody know if there is some unsafe IO function that would let me do
destructive assignment?
Something like:
a = 5
main = do
veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign a 8
print a
> 8
and yes I am in fact insane...
I'm also looking for a way to make actual copie
79 matches
Mail list logo
