is there "return" in Erlang.

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

is there "return" in Erlang.

Wang Wei
Hello, I has a question about how to convert the bellow C program into Erlang.

void judge()
{
    int a;
    int b;

    a = getA();
    if (a == CONF1)
   {
       doSomeThing(a);
       return;
   }

   b = getB();
   if (b == CONF2)
   {
       doOtherThing(b);
        return;
   }

   doThings();
   return;
}

I think about "case" and "if" construct, but none of it seems work fine, thanks for help.
Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

yted
hello Wang:
in fact "case" do work, like the codes below:

judge() ->
A = getA(),
B = getB(),
case [A,B] of
[CONF1, _] ->
doSomeThing(A);
[_, CONF2] ->
doOtherThing(B);
[_,_] ->
doThings()
end.


2011/2/28 Wang Wei <[hidden email]>

> Hello, I has a question about how to convert the bellow C program into
> Erlang.
>
> void judge()
> {
>    int a;
>    int b;
>
>    a = getA();
>    if (a == CONF1)
>   {
>       doSomeThing(a);
>       return;
>   }
>
>   b = getB();
>   if (b == CONF2)
>   {
>       doOtherThing(b);
>        return;
>   }
>
>   doThings();
>   return;
> }
>
> I think about "case" and "if" construct, but none of it seems work fine,
> thanks for help.
Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

黃耀賢 (Yau-Hsien Huang)
In reply to this post by Wang Wei
getA(), getB(), doSomeThing(...), and doThings() are other functions to be
implemented.

if structure is provided in Erlang:

   if
        test ->  calculation ;
        test ->  calculation ;
        ...
        test -> calculation
   end

It need not write `return' in Erlang. A function returns a value by the last
statement/
clause in a function.

In general, `void judge()' has a structure like:

    judge() ->
       A = getA(),
       B = getB(),
       if
            A == CONF1 -> doSomeThing(A) ;
            B == CONF2 -> doSomeThing(B) ;
            true -> doThings()
       end.


2011/2/28 Wang Wei <[hidden email]>

> Hello, I has a question about how to convert the bellow C program into
> Erlang.
>
> void judge()
> {
>    int a;
>    int b;
>
>    a = getA();
>    if (a == CONF1)
>   {
>       doSomeThing(a);
>       return;
>   }
>
>   b = getB();
>   if (b == CONF2)
>   {
>       doOtherThing(b);
>        return;
>   }
>
>   doThings();
>   return;
> }
>
> I think about "case" and "if" construct, but none of it seems work fine,
> thanks for help.




--

Best Regards.

--- Y-H. H.
Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Masklinn
In reply to this post by yted

On 2011-02-28, at 04:55 , yted wrote:

> hello Wang:
> in fact "case" do work, like the codes below:
>
> judge() ->
> A = getA(),
> B = getB(),
> case [A,B] of
> [CONF1, _] ->
> doSomeThing(A);
> [_, CONF2] ->
> doOtherThing(B);
> [_,_] ->
> doThings()
> end.
Yes, but 'tis not equivalent to the original code: `getA` and `getB` may have side-effects, in which case it would be expected that `getB` isn't executed if the first condition is true.

Closer to the original code would probably be along the lines of:

judge() ->
    case getA() of
        CONF1 -> doSomeThing(CONF1);
        _ ->
            case getB() of
                CONF2 -> doOtherThing(CONF2);
                _ -> doThings()
            end
    end.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Jachym Holecek
In reply to this post by Wang Wei
# Wang Wei 2011-02-28:
> Hello, I has a question about how to convert the bellow C program into Erlang.
>
> [...]
>
> I think about "case" and "if" construct, but none of it seems work fine, thanks for help.

And one more option:

  judge() ->
      judge(get_a(), get_b()).

  judge(A, _) when A == conf1 ->
      do_some_thing(A);
  judge(_, B) when B == conf2 ->
      do_other_thing(B);
  judge(_, _) ->
      do_things().

This assumes get_b() doesn't have some kind of side effects you'd like to
suppress in case the get_a() branch hits -- usually not the case in Erlang,
but if so, the solution with nested cases would be more appropriate.

Point of this is you can break your code into small trivial functions that
solve clearly defined parts of the problem, instead of writing long and
complex functions that try to handle the whole thing. Being a lazy person,
I find the former style easier to read, but YMMV.

And about return in general -- in Erlang (and other functional languages)
program is composed of expressions that get evaluated to values, there are
no statements. This is the reason why you do things like:

   A = case (X rem 2) of
           0 ->
               even;
           1 ->
               odd
       end

which quite annoyingly you can't do in C. Now if you're thinking "Yeah,
that's nice, but you're still a liar because exceptions don't really
evaluate to anything, they just perform weird stuff with the call stack,
don't they?" -- well, conceptually, you can convert them (and any other
forms of control transfer) to tail function calls[1] and everything is
back to normal.

HTH,
        -- Jachym

[1] Nice presentation on this by Marc Feeley, author of Gambit-C Scheme:

      http://www.iro.umontreal.ca/labs/ltp/mslug/schemetoc1.avi
      http://www.iro.umontreal.ca/labs/ltp/mslug/schemetoc2.avi

    Quality of the recording isn't great, but the content is worth it.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Jesper Louis Andersen-2
In reply to this post by Wang Wei
2011/2/28 Wang Wei <[hidden email]>:
> Hello, I has a question about how to convert the bellow C program into Erlang.

I've been doing exactly this for some time. The problem is that you
have two monarchies. In the empire of imperativism, the control flow
king rules, whereas the data flow queen is being forced off the
throne. If the queen wants to cheat on the king with a knight, she has
to delve into the dungeon of global scope, or sneak out to the house
of structs. There, the knight and the queen can do their naughty deed
by destructively updating a variable.

In the realm of declarativism however, the queen is so seductive and
intelligent, she effectively rules over the king. Knights here are
always passed as parameters and are never used in foreign lands for
war. Nay, a knight is for local dancing and feast. After the dance,
the knight is dutifully sent on to the next party.

> void judge()
> {

..

>    a = getA();
>    if (a == CONF1)
>   {
>       doSomeThing(a);
>       return;
>   }

The problem here is that doSomeThing(a); is done for its side-effect
only. The only possible side-effect in Erlang is that it communicates
with other processes. Otherwise, the queen has decreed that you
explicitly pass parameters, should you want to alter them, and you
will have to return the altered state back. The king tried to use
return, but it has been banned by the queen in the realm of Erlang.

Early returns can be arranged, if you conspire against the queen with
the king. The trick is to talk to the jester who can arrange for a
'throw' exception in all the return points, but the price is that you
will have to explicitly return the state as well.

--

Erlang is very data flow oriented. In other words, you need to figure
out the data flow as much as you need to figure out the control flow.
In C, you can always shove a variable in somewhere and then update it
when the control flow goes along. Never mind that it is completely
unreadable and much harder to follow. This is the main problem of
almost all the transcribings of C/Java/C++ to Erlang i've seen. When
the data flow problem became to hard, the programmer exerted his or
hers dominance over the poor data flow queen by shoving the knight
into the dungeon of an object/struct field.

To untangle such code, you must do what the original programmer did
not: figure out the data flow of the code. This often includes
creating numerous small auxiliary functions to help you in the task -
but often the result is much clearer. And the solutions are hinted
very well by others in the thread.


--
J.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Attila Rajmund Nohl
In reply to this post by Jachym Holecek
2011/2/28, Jachym Holecek <[hidden email]>:
[...]

> And about return in general -- in Erlang (and other functional languages)
> program is composed of expressions that get evaluated to values, there are
> no statements. This is the reason why you do things like:
>
>    A = case (X rem 2) of
>   0 ->
>       even;
>   1 ->
>       odd
>        end
>
> which quite annoyingly you can't do in C.

I might misunderstand something, but

A = (X % 2 == 0) ? even : odd;

can be done in C ...

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

黃耀賢 (Yau-Hsien Huang)
In reply to this post by Jesper Louis Andersen-2
On Mon, Feb 28, 2011 at 9:15 PM, Jesper Louis Andersen <
[hidden email]> wrote:

> 2011/2/28 Wang Wei <[hidden email]>:
> > Hello, I has a question about how to convert the bellow C program into
> Erlang.
>
> I've been doing exactly this for some time. The problem is that you
> have two monarchies. In the empire of imperativism, the control flow
> king rules, whereas the data flow queen is being forced off the
> throne. If the queen wants to cheat on the king with a knight, she has
> to delve into the dungeon of global scope, or sneak out to the house
> of structs. There, the knight and the queen can do their naughty deed
> by destructively updating a variable.
>
> In the realm of declarativism however, the queen is so seductive and
> intelligent, she effectively rules over the king. Knights here are
> always passed as parameters and are never used in foreign lands for
> war. Nay, a knight is for local dancing and feast. After the dance,
> the knight is dutifully sent on to the next party.
>
>
GOOD fairy tale, I like it!

In functional programming, I'd like to have a basic program:

    compare(Subject, Object, DoFunc) ->
        if
            Subject == Object -> apply(DoFunc, [Subject]) ;
            true -> nil
        end.

that I'll get something done when a test is passed or otherwise nothing.
Then I can test cases A, B, C, and so on by using compare/3.

I need a control flow function:

    test_seq( [] ) -> ok ;
    test_seq( [{S,O,F}|SOFs] ) ->
        case compare(S, O, F) of
            nil -> test_seq(SOFs) ;
            Result -> apply(F, [S])
        end.

It won't return any data because in imperative world things are effected but
picked. By doing a function-call

    test_seq( [{ getA(), CONF1, fun doSomeThing/1}
                  , { getB(), CONF2, fun doSomeThing/1 } ] ),

I get it work. However, for imperative purpose, the state of a program is
very important. There may be a states-handling function manage/N, and
an environment should be added into and approached inside test_seq/1:

    test_seq( State, [] ) -> State ;
    test_seq( State, [{S,O,F}|SOFs] ) ->
        case compare(S, O, F) of
            nil -> test_seq(State, SOFs) ;
            Result -> manage(State, apply, F, [S])
        end.

that manage/N takes care of State.

--
Y.-H. H.
Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Masklinn
In reply to this post by Jesper Louis Andersen-2
On 2011-02-28, at 14:15 , Jesper Louis Andersen wrote:
> 2011/2/28 Wang Wei <[hidden email]>:
> The problem here is that doSomeThing(a); is done for its side-effect
> only. The only possible side-effect in Erlang is that it communicates
> with other processes.

Well yeah but via this it can communicate with databases, other processes on the same machine, web services, etc…

It's not like Erlang puts *any* restriction on side-effects within a function (as opposed to, say, Haskell)


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Masklinn
In reply to this post by Attila Rajmund Nohl

On 2011-02-28, at 14:59 , Attila Rajmund Nohl wrote:

> 2011/2/28, Jachym Holecek <[hidden email]>:
> [...]
>> And about return in general -- in Erlang (and other functional languages)
>> program is composed of expressions that get evaluated to values, there are
>> no statements. This is the reason why you do things like:
>>
>>   A = case (X rem 2) of
>>   0 ->
>>       even;
>>   1 ->
>>       odd
>>       end
>>
>> which quite annoyingly you can't do in C.
>
> I might misunderstand something, but
>
> A = (X % 2 == 0) ? even : odd;
>
> can be done in C …
Yes, his case was overly simplistic and thus easy to reproduce with a ternary. But a ternary is not going to scale very far (not without making the next person having to maintain your code go postal) whereas a case can grow quite a bit (in number of patterns, for instance)
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Jachym Holecek
In reply to this post by Attila Rajmund Nohl
# Attila Rajmund Nohl 2011-02-28:

> 2011/2/28, Jachym Holecek <[hidden email]>:
> [...]
> > And about return in general -- in Erlang (and other functional languages)
> > program is composed of expressions that get evaluated to values, there are
> > no statements. This is the reason why you do things like:
> >
> >    A = case (X rem 2) of
> >   0 ->
> >       even;
> >   1 ->
> >       odd
> >        end
> >
> > which quite annoyingly you can't do in C.
>
> I might misunderstand something, but
>
> A = (X % 2 == 0) ? even : odd;
>
> can be done in C ...

Oh, true, forgot about that -- but the one with 'if' can't, or consider
'switch' as another example. Point is in C, some things are statements
which do things without having a value themselves and some things are
expressions yielding values.

In Erlang, life is simpler -- everything is an expression, you can bind it
to a variable or just use it in-place anywhere an expression is allowed.
This means you can compose small bits of meaning in any way you want, free
from arbitrary limitations like the ones in C.

So "special" constructs in Erlang, like 'case' or 'if', are really just
syntactic sugar on top of lambdas (the strange scoping rule of 'case'
breaks the most straightforward approach to this, but can still be dealt
with cleanly).

I think this is a very powerful property, although as you can see I have
a bit of a trouble in clearly expressing why is that. ;-)

Take care,
        -- Jachym

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Attila Rajmund Nohl
2011/2/28, Jachym Holecek <[hidden email]>:
[...]
> Oh, true, forgot about that -- but the one with 'if' can't, or consider
> 'switch' as another example. Point is in C, some things are statements
> which do things without having a value themselves and some things are
> expressions yielding values.
>
> In Erlang, life is simpler -- everything is an expression, you can bind it
> to a variable or just use it in-place anywhere an expression is allowed.

Except the throw statement...

> This means you can compose small bits of meaning in any way you want, free
> from arbitrary limitations like the ones in C.

Erlang has its own set of "arbitrary limitations", for example you
can't write any kind of exception in an 'if'...

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Ulf Wiger
In reply to this post by Jesper Louis Andersen-2

On 28 Feb 2011, at 14:15, Jesper Louis Andersen wrote:

> The problem here is that doSomeThing(a); is done for its side-effect
> only. The only possible side-effect in Erlang is that it communicates
> with other processes

Well, there are other ways - all of which could be modelled using processes,
but in fact aren't (updating ets tables or the process dictionary, for example),
but I agree with your point, and want to emphasise it.

One thing that will grow in importance as you learn to appreciate the differences
between pure and impure code, is that code like this - which can *only* be useful
through side-effects - has a toxic effect on your code structure.

Even if functions depend on side effects for their operation, it is a very good idea
to design the calling structure as if they didn't.

Act as if you were pure, and… well, purity won't be given to you, but at least you can convert later.

A good example is the ets API. Kresten used Clojure's persistent collections to implement
ets tables in the JVM, but whereas persistent collections are immutable by design, ets
tables have an imperative API that makes it impossible for them to inherit some of the really
cool features of persistent collections. In the old days of single-core machines, ets tables
were used a lot for performance. On SMP machines, they turn out to be among the hardest
parts of erlang to make scalable. This is in no small part due to the fact that the API enforces
a shared-memory mindset.

BR,
Ulf

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com




________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Frédéric Trottier-Hébert
In reply to this post by Jachym Holecek


On 2011-02-28, at 09:18 AM, Jachym Holecek wrote:

> # Attila Rajmund Nohl 2011-02-28:
>
> So "special" constructs in Erlang, like 'case' or 'if', are really just
> syntactic sugar on top of lambdas (the strange scoping rule of 'case'
> breaks the most straightforward approach to this, but can still be dealt
> with cleanly).
>
> I think this is a very powerful property, although as you can see I have
> a bit of a trouble in clearly expressing why is that. ;-)
>
> Take care,
> -- Jachym
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:[hidden email]
>


This is not exactly true. The 'case ... of' expression has special scoping rules that do not fit those of lambdas or functions in general:

1> case 1 of _ -> R = 3 end.
3
2> R.
3

Compare with a fun/lambda:

3> (fun(_) -> D = 3 end)(1).
3
4> D.
* 1: variable 'D' is unbound

And the 'if' expression follows the same pattern. Moreover, in a fun, you will 'shadow' the variables in the head, meaning you'll overwrite them if they existed in the current context. A case expression won't -- using the same binding of 'R = 3' as above:

5> case 2 of R -> yay end.
** exception error: no case clause matching 2


From what I heard, the underlying dispatching principle is similar, but yeah. They're not equivalent in how they handle scoping or binding.


--
Fred Hébert
http://www.erlang-solutions.com


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Attila Rajmund Nohl
In reply to this post by Masklinn
2011/2/28, Masklinn <[hidden email]>:

>
> On 2011-02-28, at 14:59 , Attila Rajmund Nohl wrote:
>
>> 2011/2/28, Jachym Holecek <[hidden email]>:
>> [...]
>>> And about return in general -- in Erlang (and other functional languages)
>>> program is composed of expressions that get evaluated to values, there
>>> are
>>> no statements. This is the reason why you do things like:
>>>
>>>   A = case (X rem 2) of
>>>   0 ->
>>>       even;
>>>   1 ->
>>>       odd
>>>       end
>>>
>>> which quite annoyingly you can't do in C.
>>
>> I might misunderstand something, but
>>
>> A = (X % 2 == 0) ? even : odd;
>>
>> can be done in C …
> Yes, his case was overly simplistic and thus easy to reproduce with a
> ternary. But a ternary is not going to scale very far (not without making
> the next person having to maintain your code go postal) whereas a case can
> grow quite a bit (in number of patterns, for instance)

That's where "else if" comes into play in imperative languages. It
might not be that elegant if the variable has to get a value in each
branch, on the other hand it might be possible that there's no real
need for that variable to get a value...

Don't forget that "Erlang is a functional language" is a nice fairy
tale, but in reality Erlang is used to control stuff or communicate
with the outside world, so the side-effects are very important and
many case clauses contain only an 'ok' atom (because something had to
be returned, even if nobody cares). Real-world example:

update_index_next(measTable, Reply, NewCols, RowIndex) ->
    maybe_start_measurement(NewCols),
    update_index_next(?measRowStatus, ?indexKey, Reply, NewCols, RowIndex).

maybe_start_measurement(NewCols) ->
    case {get_value_from_column_list(?measRowStatus, NewCols),
          get_value_from_column_list(?measAdminStatus, NewCols)} of
        {?measRowStatus_active, ?measAdminStatus_up} ->
            really_start_measurement(NewCols);
        _ ->
            dont_start_measurement
    end.

Obviously only the side-effect is important, still, two totally
meaningless line had to be written.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Jesper Louis Andersen-2
In reply to this post by Ulf Wiger
On Mon, Feb 28, 2011 at 15:46, Ulf Wiger <[hidden email]> wrote:

>
> On 28 Feb 2011, at 14:15, Jesper Louis Andersen wrote:
>
>> The problem here is that doSomeThing(a); is done for its side-effect
>> only. The only possible side-effect in Erlang is that it communicates
>> with other processes
>
> Well, there are other ways - all of which could be modelled using processes,
> but in fact aren't (updating ets tables or the process dictionary, for example),
> but I agree with your point, and want to emphasise it.
>
> One thing that will grow in importance as you learn to appreciate the differences
> between pure and impure code, is that code like this - which can *only* be useful
> through side-effects - has a toxic effect on your code structure.

Indeed the problem is that code with side effects are toxic in many
ways. Other programmers can't easily follow the code, there is no
persistence since the side effect leaks, and non-pure functions are
harder to test since you need to mock the side-effects. Further, such
code is not inherently easy to make parallel because of the
impurities. I took the pure view + processes because of simplicity.
Another (monadic) effect which is important are exceptions, but they
were forgotten by me and they do not have a direct process-like
description.

My main point is this though: In (pure) functional programs, the data
flow is as important than the control flow, if not more. If you can
restructure your program so it passes fewer parameters and splits the
data flow, then it is often much more readable. Deeply nested calls
where many functions "along the way" just passes parameters for the
inner function is often better written without the passing and then
returning some value you can call at the top level. For instance:

   f(A,B,C) -> g(A, B, C) -> h(B, C)

is a call chain of f() -> g() -> h() where g has to pass on B and C
because h needs them. If we rearrange such that g does not *call* h,
but instead returns some value which h can be called with, you get an
altered flow:

   f(A,B,C) ->
     R = g(A),
     h(R, B, C)

untangling g from the chain and making it a lot simpler. Often h
doesn't grow much nastier in the process. A naive programmer will
often just shove B and C into the fields of an object or pass it as
global state because it looks easier. But it also hides the coupling
of the functions and using h otherwise now requires the programmer to
follow an undocumented protocol. Worse, many imperative languages put
*severe* restrictions upon the R above, so it is not even possible to
write the code in a data-flow oriented style. The queen has
effectively been beheaded :/


--
J.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Jachym Holecek
In reply to this post by Frédéric Trottier-Hébert
# Frédéric Trottier-Hébert 2011-02-28:

> On 2011-02-28, at 09:18 AM, Jachym Holecek wrote:
> > # Attila Rajmund Nohl 2011-02-28:
> > So "special" constructs in Erlang, like 'case' or 'if', are really just
> > syntactic sugar on top of lambdas (the strange scoping rule of 'case'
> > breaks the most straightforward approach to this, but can still be dealt
> > with cleanly).
> >
> > I think this is a very powerful property, although as you can see I have
> > a bit of a trouble in clearly expressing why is that. ;-)
>
> This is not exactly true. The 'case ... of' expression has special scoping
> rules that do not fit those of lambdas or functions in general:

Yes, I've mentioned this explicitely.

> 1> case 1 of _ -> R = 3 end.
> 3
> 2> R.
> 3
>
> Compare with a fun/lambda:
>
> 3> (fun(_) -> D = 3 end)(1).
> 3
> 4> D.
> * 1: variable 'D' is unbound

Compare with:

  R = (fun (_) -> 3 end(1))

It's a slightly more involved transform in that you have to push variables
bound in case's branches into its return value automatically, but in priciple
it still works.

> And the 'if' expression follows the same pattern. Moreover, in a fun, you
> will 'shadow' the variables in the head, meaning you'll overwrite them if
> they existed in the current context. A case expression won't -- using the
> same binding of 'R = 3' as above:
>
> 5> case 2 of R -> yay end.
> ** exception error: no case clause matching 2

Yes, so you'll be careful to disambiguate variables in that case.

> From what I heard, the underlying dispatching principle is similar, but yeah.
> They're not equivalent in how they handle scoping or binding.

Which is something a sufficiently diligent code translator can deal with.

Don't forget my point is lambdas are, in principle, all you need to express
the remaining control flow constructs. I'm not saying it's a practical thing
to do, I'm saying that unlike in C you can isolate a basic building block
of the language, so as to say -- everything else revolves around it, so you
don't have to pollute your mind with an assortment of weird pieces that
sometimes fit together, but not quite all the time.

Hope this makes my previous post a bit clearer.

Regards,
        -- Jachym

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Masklinn
In reply to this post by Ulf Wiger
On 2011-02-28, at 15:46 , Ulf Wiger wrote:

> On 28 Feb 2011, at 14:15, Jesper Louis Andersen wrote:
>
>> The problem here is that doSomeThing(a); is done for its side-effect
>> only. The only possible side-effect in Erlang is that it communicates
>> with other processes
>
> Well, there are other ways - all of which could be modelled using processes,
> but in fact aren't (updating ets tables or the process dictionary, for example),
> but I agree with your point, and want to emphasise it.
>
> One thing that will grow in importance as you learn to appreciate the differences
> between pure and impure code, is that code like this - which can *only* be useful
> through side-effects - has a toxic effect on your code structure.
>
In this precise case though, pure-but-extremely-expensive functions would probably have a similar effect (though not completely unrecoverable from, as opposed to impure functions).
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Masklinn
In reply to this post by Attila Rajmund Nohl
On 2011-02-28, at 15:57 , Attila Rajmund Nohl wrote:
>
> Don't forget that "Erlang is a functional language" is a nice fairy
> tale, but in reality Erlang is used to control stuff or communicate
> with the outside world, so the side-effects are very important and
> many case clauses contain only an 'ok' atom (because something had to
> be returned, even if nobody cares).
This is the case for most functional languages (the subset of functional languages which are *pure* is pretty damn small, if you actually look it up). And even "pure" functional languages (e.g. Haskell) have to deal with the outside world at some point.

That sequential erlang is a functional language is a plain and simple fact, it just isn't a *pure* functional language. But that's a different bucket of filth.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is there "return" in Erlang.

Jachym Holecek
In reply to this post by Attila Rajmund Nohl
# Attila Rajmund Nohl 2011-02-28:

> 2011/2/28, Jachym Holecek <[hidden email]>:
> [...]
> > Oh, true, forgot about that -- but the one with 'if' can't, or consider
> > 'switch' as another example. Point is in C, some things are statements
> > which do things without having a value themselves and some things are
> > expressions yielding values.
> >
> > In Erlang, life is simpler -- everything is an expression, you can bind it
> > to a variable or just use it in-place anywhere an expression is allowed.
>
> Except the throw statement...

What do you mean? Throw and friends are not statements but functions and
there's not necessarily anything magic about them, on conceptual level,
as I've tried to allude to earlier.

> > This means you can compose small bits of meaning in any way you want, free
> > from arbitrary limitations like the ones in C.
>
> Erlang has its own set of "arbitrary limitations", for example you
> can't write any kind of exception in an 'if'...

Yeah, for some reason unknown to me 'if' only likes guard tests, but at least
it's not like there aren't perfectly usable alternatives to this. I suppose
your point was that nothing is perfect, with which I of course agree, and
I hope my point about the value of consistency (or how else to put it) didn't
get lost in the details.

Regards,
        -- Jachym

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

12