| Author |
Message |
|
| bhyde at pobox.com |
 Posted: Fri Dec 18, 1998 10:53 pm |
 |
|
|
Guest
|
So is this good or bad? - ben
----
-module(hack).
-export(black_box/1]).
black_box(X) -> [ begin io:format("~p
", [E]), E end || E <- X ].
----
(z_at_zap)28>c(hack)
{ok,hack}
(z_at_zap)29>hack:black_box([1,2,3,4]).
4
3
2
1
[1,2,3,4]
(z_at_zap)30> [begin io:format("~p
", [E]), E end || E <- [1,2,3]].
1
2
3
[1,2,3]
(z_at_zap)31>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| klacke at erix.ericsson.s |
| Posted: Fri Dec 18, 1998 11:42 pm |
|
|
|
Guest
|
Ben Hyde writes:
>
> So is this good or bad? - ben
>
> ----
> -module(hack).
> -export(black_box/1]).
> black_box(X) -> [ begin io:format("~p
", [E]), E end || E <- X ].
> ----
>
> (z_at_zap)28>c(hack)
> {ok,hack}
> (z_at_zap)29>hack:black_box([1,2,3,4]).
> 4
> 3
> 2
> 1
> [1,2,3,4]
> (z_at_zap)30> [begin io:format("~p
", [E]), E end || E <- [1,2,3]].
> 1
> 2
> 3
> [1,2,3]
> (z_at_zap)31>
>
Well it teaches us to write code with side effects that is not
dependent on the evaluation order of arguments.
Whenever we have side effects (such as messages or io) it is
always a good idea to make it clear that one expression is evaluated
before or after another.
In this case you are running compiled code in the first case and
erl_eval.erl (The interpreter in the second) and they are two
implementations of the same thing that happen to have different
evaluation order on lists. I.e the interpreter evals as
eval([H|T]) ->
eval(H),
eval(T).
whereas the compiler will lay out code that evaluates the tail first.
So, to answer you question: It is bad, sort of. We should have a fixed
evaluation order and for lists it ought to be head first, tail last.
We also have things like tuples:
{io:format("a", []), io:format("b",[])}.
and function calls:
funky:foo(io:format("a", []), io:format("b",[]).
In the long lengthy dry dry dry specification doc at www.erlang.org we
have decided that in the next major release we shall have fixed
and decided evaluation order.
This has never been an issue for me personally since if I want to have
an explicit order on evaluation, I always write my code in such away
that the eval order is clear.
Cheers
/klacke
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| bhyde at pobox.com |
| Posted: Sat Dec 19, 1998 1:15 am |
|
|
|
Guest
|
tuning in later...
box_top(X)->[E||E<-X,begin io:format("~p
", [E]), true end].
black_box(X)->[begin io:format("~p
", [E]), E end||E<-X].
black_n_blue(X) ->
[begin io:format("assemble: ~p
", [E]), E end
|| E<-X,
begin io:format("filter: ~p
", [E]), true end].
...>hack:box_top([1,2,3]).
1
2
3
[1,2,3]
...>hack:black_box([1,2,3]).
3
2
1
[1,2,3]
...>hack:black_n_blue([1,2,3]).
filter: 1
filter: 2
filter: 3
assemble: 3
assemble: 2
assemble: 1
[1,2,3]
...>
Does the spec preclude interleaving the accumulation with
the iteration?
Looping, nothing but trouble.
Claes Wikstrom writes:
> ... we
>have decided that in the next major release we shall have fixed
>and decided evaluation order.
Functional and deterministic! Imagine! - ben
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| 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
