[erlang-questions] Extensions to comprehensions eeps

Hynek Vychodil vychodil.hynek@REDACTED
Thu Jul 31 12:05:15 CEST 2008


On Thu, Jul 31, 2008 at 9:59 AM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:

> 2008/7/31 Hynek Vychodil <vychodil.hynek@REDACTED>
>
>> There is functional difference, between <- and <= is not functional
>> difference.
>> There is not reason why
>> [X || <<X>> <- <<"abc">> ].
>> should not return same result as
>>  > [X || <<X>> <= <<"abc">> ].
>> "abc"
>>
>
> Hi,
>
> I might be mistaken here, but I think the issue is that the compiler
> generates completely different code for each case and when the generator
> looks like X <- Y, i.e. the right side is not a constant, it has to know
> which one to produce. The compiler can't guess from the source code, because
> for example <<X>> <- L is a very normal list generator, one can't assume L
> is a binary.
>
> best regards,
> Vlad
>
>
I understand it, but I think this is wrong design decision. Compiler
optimization should not impact language design, especially in so clear
functional language as Erlang is. {joke, "It should not evolve in ugliness
of assembly language"}. For example, in some lisp compilers, I heard, are
two entry point to function, with and without parameters check and so. And
HiPE do some optimization for float only functions ... This is better way
how deal with it. Changing language to solve some special low level
optimizations is wrong idea.

do_it(L) when is_list(L) -> [X+1, <<X>> <- L];
do_it(B) when is_binary(B) -> [X+1, <<X>> <- B]. % [X+1, <<X>> <= B]

should be same as

do_it(Y) -> [X+1, <<X>> <- Y].

and deal with it is compiler business.


-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080731/1de1c882/attachment.htm>


More information about the erlang-questions mailing list