| Author |
Message |
|
| kagato |
 Posted: Fri Sep 18, 2009 8:39 am |
 |
|
|
User
Joined: 30 Dec 2007
Posts: 85
|
> Not so. The inner fun() executes within a transactional context
> (that of mnesia) and only uses functions relative to that context,
> which means the context manager can handle errors & retries
> gracefully.
Okay, the inner fun() has intended side-effects.
The point was, if the inner function had any OTHER side effects, it
couldn't be retried.
So, -1 for actually having intended but subtle side effects, but +1000
for showing a real case of when and why they're important--which was
the poster's question.
--
Jayson Vantuyl
kagato@souja.net
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
 
|
| Guest |
| Posted: Fri Sep 18, 2009 9:50 am |
|
|
|
Guest
|
Masklinn wrote:
>
> Not so. The inner fun() executes within a transactional context (that of
> mnesia) and only uses functions relative to that context, which means
> the context manager can handle errors & retries gracefully.
Associating freely and spinning the whole thing into
a much more abstract sphere, mnesia transactions are
in some ways similar to Transaction Monads in Haskell,
except in Haskell, the compiler can actually enforce
these things for you.
Haskell is special in that it identifies side effects
as a very special operation, with its own type.
It handles side effects using a special construct,
called the monad. This scares the life out of most
people, but allows Haskell programmers to apply a
whole set of sound laws on expressions that contain
side effects, and determine, e.g. if different expressions
containing side effects are equivalent.
This presentation from the ICFP Haskell workshop in Edinburgh,
given by "Oscar winner" Dan Piponi, is a wonderful attempt at
describing these monad laws in terms that mere mortals can
understand.
http://www.vimeo.com/6590617
Simon Peyton-Jones once said that they should have called
monads "warm fuzzy things" instead. Perhaps not, but at least,
many of the important aspects of monads can be illustrated
using warm fuzzy things.
Tying back to the initial question (and apologies for raising
it into the stratosphere), you could say that if you _do_
clearly separate pure logic from side effects, and you do it
right, infinite power lies within your reach. 
BR,
Ulf W
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 18, 2009 11:53 am |
|
|
|
Guest
|
Exceptions too?
On Fri, Sep 18, 2009 at 4:47 AM, Jayson Vantuyl <kagato@souja.net> wrote:
> A small addendum.
>
> Note that calling unsafe functions can create side-effects. |
|
|
| Back to top |
|
| kagato |
| Posted: Fri Sep 18, 2009 12:42 pm |
|
|
|
User
Joined: 30 Dec 2007
Posts: 85
|
Actually, I'm not entirely sure that an exception would be a side
effect. It doesn't get "returned" like a normal value, but I don't
see that it changes state any more than a return value does.
Put another way, a function has "no side-effects" if all the data goes
in through the parameters and a result comes out the end--without
anything else being touched. This means that we can safely optimize
that call away, or run with a thousand different inputs in parallel
(on a bunch of processors), or do any number of things without worry
about two parallel executions of it stepping on each others toes.
So, taking another stab at Kaiduan's question, maybe it's best
illustrated by contrast. Having "no side-effects" is most important
when you have concurrent code.
In Erlang, no two processes share state that can be changed. If you
change state in one process, it never changes in another one. In this
way, a process has no "side effects" unless you choose to make some.
Contrast this with the normal way of using shared memory with
threads. In these languages, you have multiple threads trying to lock
access to shared resources (or using complex lockless methods). The
complications of avoiding deadlocks or generating correct behavior in
threaded systems are very difficult compared to Erlang's isolation.
Instead of having a bunch of processes fighting over shared resources,
we let resources be owned by individual processes only, but give a
powerful way to communicate among them. This isolation is embodied in
the concept that no simple Erlang function can touch another process's
state, thus there are no "side-effects" that the other process has to
worry about. All side effects are contained in a few operations that
are easily handled.
Understanding the impact of delivering messages to mailboxes and
spawning processes (which is 99% of side-effects in Erlang code) is
much easier to debug and much easier to understand than finding race
conditions with complex locking regimes, implementing even the
simplest of lockless algorithms portably, or using system IPC to
manage concurrency. With the possible exception of Software
Transactional Memory, there doesn't seem to be much of anything that
comes closer to simplifying concurrent programming.
On Sep 18, 2009, at 4:52 AM, Ovidiu Deac wrote:
> Exceptions too?
>
> On Fri, Sep 18, 2009 at 4:47 AM, Jayson Vantuyl <kagato@souja.net>
> wrote:
>> A small addendum.
>>
>> Note that calling unsafe functions can create side-effects. Things
>> like
>> gen_server:call, for example, send messages. So you need to be
>> careful with
>> library functions.
>>
>> Thinking a bit, other times that you can modify state:
>>
>> * Changing the process dictionary (most people don't really do this)
>> * ETS tables (messages in disguise)
>> * DETS tables (messages in disguise)
>> * Network Connections (messages in disguise)
>> * digraphs (messages in disguise)
>>
>> On Sep 17, 2009, at 6:35 PM, Jayson Vantuyl wrote:
>>
>>> I'll do better. Here's an example that actually is necessary.
>>>
>>> Assume you have two processes. One updates a record in Mnesia,
>>> the other
>>> receives an acknowledgement that it did it.
>>>
>>> Mnesia can replay a transaction in times of extreme contention.
>>> Here's a
>>> buggy version of a function that charges some account. Look at
>>> the fun()
>>> inside. It has the side-effect that it sends a message to another
>>> process.
>>>
>>>> charge_account(Requestor,UserId,Amount) ->
>>>> {atomic,ok} = mnesia:transaction(
>>>> fun() ->
>>>> [ Current ] = mnesia:read(account,UserId),
>>>> OldAmount = Current#account.amount,
>>>> New = Current#account{ amount = OldAmount - Amount },
>>>> ok = mnesia:write(New),
>>>> Requestor ! {updated,New},
>>>> ok
>>>> end
>>>> ).
>>>
>>> This function will potentially send the message to Requestor
>>> multiple
>>> times if the transaction has to be retried.
>>>
>>> If you want to do this correctly, you can simply modify the
>>> function like
>>> this:
>>>
>>>> charge_account(Requestor,UserId,Amount) ->
>>>> {atomic,Result} = mnesia:transaction(
>>>> fun() ->
>>>> [ Current ] = mnesia:read(account,UserId),
>>>> OldAmount = Current#account.amount,
>>>> New = Current#account{ amount = OldAmount - Amount },
>>>> ok = mnesia:write(New),
>>>> New
>>>> end,
>>>> Requestor ! {updated,Result},
>>>> ).
>>>
>>> The inner fun() has no side-effects and can now be safely retried by
>>> Mnesia.
>>>
>>> This is only one instance where side-effects matter. The
>>> important thing
>>> to remember is that state data in Erlang takes the form of
>>> recursion,
>>> processes and messages. If you don't create recurse with a
>>> modified value,
>>> create a process, or send a message, then no state is changed.
>>> Even when
>>> you recurse, your state only affects a single process. This
>>> property makes
>>> it very easy to create very stable programs, because you can
>>> contain the
>>> places that state can get corrupted or lost.
>>>
>>> Hopefully this helps.
>>>
>>> On Sep 17, 2009, at 6:17 PM, Kaiduan Xie wrote:
>>>
>>>> Thanks all for the reply. Can someone provide an example in code?
>>>> For
>>>> example, a side-effect free function, and its counterpart function
>>>> with side-effect.
>>>>
>>>> Thanks,
>>>>
>>>> kaiduan
>>>>
>>>> On Thu, Sep 17, 2009 at 11:07 AM, Gene Tani <gene.tani@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Sep 16, 3:26 pm, Kaiduan Xie <kaidu...@gmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Can someone explain what does side-effect means in Erlang? What
>>>>>> is
>>>>>> side-effect free function, and why we need to write side-effect
>>>>>> free
>>>>>> function? A concrete example is preferred.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> kaiduan
>>>>>>
>>>>>> ________________________________________________________________
>>>>>> erlang-questions mailing list. Seehttp://www.erlang.org/faq.html
>>>>>> erlang-questions (at) erlang.org
>>>>>
>>>>> http://blog.tornkvist.org/blog.yaws?id=1239107937892262
>>>>>
>>>>>
>>>>> http://www.cs.chalmers.se/Cs/Grundutb/Kurser/ppxt/HT2007/general/languages/armstrong-erlang_history.pdf
>>>>> (PDF page 14)
>>>>>
>>>>> and a FP vs. OO debate:
>>>>>
>>>>> http://news.ycombinator.com/item?id=493963
>>>>>
>>>>> ________________________________________________________________
>>>>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>>>>> erlang-questions (at) erlang.org
>>>>>
>>>>>
>>>>
>>>> ________________________________________________________________
>>>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>>>> erlang-questions (at) erlang.org
>>>>
>>>
>>>
>>>
>>> --
>>> Jayson Vantuyl
>>> kagato@souja.net
>>>
>>>
>>>
>>
>>
>>
>> --
>> Jayson Vantuyl
>> kagato@souja.net
>>
>>
>>
>>
>> ________________________________________________________________
>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>> erlang-questions (at) erlang.org
>>
>>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
--
Jayson Vantuyl
kagato@souja.net
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 18, 2009 1:04 pm |
|
|
|
Guest
|
Jayson Vantuyl wrote:
> Actually, I'm not entirely sure that an exception would be a side
> effect. It doesn't get "returned" like a normal value, but I don't see
> that it changes state any more than a return value does.
It straddles the fence in some ways. Functions can be pure for all
legal input and raise exceptions for illegal input. This is fine,
but there are also functions that raise exceptions even for legal
input.
Consider the following code:
pmap(F, L) ->
Pids = [spawn_monitor(fun() ->
exit({ok, F(X)})
end) || X <- L],
[receive {'DOWN',Ref,_,_,R} -> unwrap(R) end
|| {_,Ref} <- Pids].
(A simplified version of slide 7 in this talk:
http://www.erlang-factory.com/upload/presentations/56/UlfWiger_ErlangMulticoreEF.pdf)
While it might seem contrived, the shell evaluator
does roughly the same thing: evaluates the expression
inside an exit() call in order to deliver the result and
die in one and the same action.
Such functions are only meaningful when considering their
side-effects - the exceptions.
BR,
Ulf W
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 18, 2009 1:07 pm |
|
|
|
Guest
|
On 18 Sep 2009, at 11:48 , Ulf Wiger wrote:
> Masklinn wrote:
>> Not so. The inner fun() executes within a transactional context
>> (that of mnesia) and only uses functions relative to that context,
>> which means the context manager can handle errors & retries
>> gracefully.
>
> Associating freely and spinning the whole thing into
> a much more abstract sphere, mnesia transactions are
> in some ways similar to Transaction Monads in Haskell,
> except in Haskell, the compiler can actually enforce
> these things for you.
>
Very much so, but I didn't want to delve too deep into it as I don't
have a very good knowledge of Haskell's STM.
> Haskell is special in that it identifies side effects
> as a very special operation, with its own type.
> It handles side effects using a special construct,
> called the monad.
It handles many things going far beyond mere side-effects using monads
(Haskell's lists are monads for example, and so is its option type
Maybe, which has pretty nice properties), but yes Haskell does use
monads quite a lot to segregate side-effecting code from "pure" code
(and has various monad types for various kinds of side-effects to
ensure "incompatible" side-effects -- such as transactions & IO --
can't be interleaved)
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| MononcQc |
| Posted: Fri Sep 18, 2009 1:45 pm |
|
|
|
User
Joined: 14 Aug 2009
Posts: 37
Location: Quebec, Canada
|
On Fri, Sep 18, 2009 at 9:03 AM, Ulf Wiger
<ulf.wiger@erlang-consulting.com>wrote:
> Jayson Vantuyl wrote:
>
>> Actually, I'm not entirely sure that an exception would be a side effect.
>> It doesn't get "returned" like a normal value, but I don't see that it
>> changes state any more than a return value does.
>>
>
> It straddles the fence in some ways. Functions can be pure for all
> legal input and raise exceptions for illegal input. This is fine,
> but there are also functions that raise exceptions even for legal
> input.
>
> Consider the following code:
>
> pmap(F, L) ->
> Pids = [spawn_monitor(fun() ->
> exit({ok, F(X)})
> end) || X <- L],
> [receive {'DOWN',Ref,_,_,R} -> unwrap(R) end
> || {_,Ref} <- Pids].
>
> (A simplified version of slide 7 in this talk:
>
> http://www.erlang-factory.com/upload/presentations/56/UlfWiger_ErlangMulticoreEF.pdf
> )
>
> While it might seem contrived, the shell evaluator
> does roughly the same thing: evaluates the expression
> inside an exit() call in order to deliver the result and
> die in one and the same action.
>
> Such functions are only meaningful when considering their
> side-effects - the exceptions.
>
> BR,
> Ulf W
> --
> Ulf Wiger
> CTO, Erlang Training & Consulting Ltd
> http://www.erlang-consulting.com
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
Wouldn't the ability to just drop in and either catch errors and exit signal
or trap them in a monitor mean exceptions and errors are not necessarily
side effects, no matter the purpose of the function?
Tthe caller's side doing:
case catch Mod:Fun(Args) of
{ok, X} -> X;
{'EXIT',Reason} -> ...
end.
Pretty much ends up transforming an error into a returnable value. There is
no visible difference between the function called having an error or just
returning {'EXIT',Reason} as a normal value, no matter the intent of the
programmer.
(I guess what I'm saying is a bit similar to what you are saying, in the
end)
Post received from mailinglist |
|
|
| Back to top |
|
| wuji |
| Posted: Wed Aug 15, 2012 6:08 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
will always be remembered for her intelligence, beauty, compassion, humor humor cheap Ralph Lauren humor and her kind heart," her family wrote in her
Secret Addiction: Stepping Out of Adderall's ShadowBetween 2002 and 2010, 2010, designer replica *beep* 2010, a 750 Percent Increase in Adderall Prescriptions for
26 to 39By DAN HARRIS and LANA ZAKJune 26, 2012 2012 cheap Ralph Lauren Polo 2012 All over America there are moms in the shadows
in their daily responsibilities and turning to the prescription drug drug replica designer *beep* drug Adderall for relief.Adderall is a drug for attention deficit
disorder, but these women don't have ADHD; they say they they [h2]cheap Ralph Lauren Polo[/h2] they need Adderall to be better mothers.Between 2002 and 2010,
been a 750 percent increase in Adderall prescriptions for women women [h3]discount designer *beep*[/h3] women between 26 and 39. Critics say clearly not all |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
