> Thanks, Robert, that helps clarify the state of things.
> Do you think it would be useful if it worked "the way I would like"?
> It seems that in the specific case of walking a binary by extending
> the length of a sub-binary in the match (via a Len argument) would be
> much more efficient than binary accumulation which always does at
> least some allocation (256 bytes) and copying, and also more efficient
> than moving the  code into a case (where the Len will already be
> bound.) It seems that the compiler would need to notice that what it
> thinks is an unbound variable is actually guaranteed to be bound in
> another argument, and express this as a dependency in the head pattern
> match code.
> Erik.

> On Wed, Oct 31, 2012 at 11:45 AM, Robert Virding
> <robert.vird...@erlang-solutions.com> wrote:
>> I don't know if it is actually explicitly stated anywhere but multiple
>> occurrences of a variable in a pattern match means that the values the
>> variable would get in each occurrence are tested for equality. They are not
>> being used as you would like. Also the order in which function arguments are
>> matched is not defined, and if we just test multiple variable occurrences
>> for equality does not matter. This means that when you match the binary N
>> may not yet have a value. In fact we do match left-to-right (but don't tell
>> anyone) so N will in fact not have a value. Flipping the order of the
>> arguments will not help here.

>> It is different when match *INSIDE* a binary. There, by necessity, the
>> pattern match goes left-to-right and if match a value from a binary you can
>> use the value later in the binary match. So you can do:

>> <<N,B1:N/binary,Rest/binary>>  = Bin

>> Robert

>> ________________________________

>> From: "Erik Pearson" <e...@defunweb.com>
>> To: "erlang-questions Questions" <erlang-questi...@erlang.org>
>> Sent: Sunday, 28 October, 2012 11:08:44 AM
>> Subject: Re: [erlang-questions] Binary match in function head doesn't
>> compile

>> Is there a reference for the resolution of patterns in function/clause head
>> similar to

>> http://www.erlang.org/doc/apps/erts/match_spec.html

>> but for regular Erlang? The docs on the abstract format is useful

>> http://www.erlang.org/doc/apps/erts/absform.html

>> There are a few places in the docs that refer to the process of matching the
>> function clause head against arguments

>> e.g. the function overview

>> http://www.erlang.org/doc/reference_manual/functions.html#id74558

>> but it would be really useful to have those references link to documentation
>> which describes this process.

>> Thanks,
>> Erik.

>> (ps - I'm happy with your answer, Björn-Egil, but hoping this thread can
>> include some solid leads for others researching similar issues.)

>> (pps - there is a definitive response to my original post from Björn-Egil
>> Dahlberg below -- he inadvertently sent it directly to me)

>> On Fri, Oct 26, 2012 at 11:59 AM, Björn-Egil Dahlberg
>> <wallentin.dahlb...@gmail.com> wrote:

>>> 2012/10/26 Erik Pearson <e...@defunweb.com>

>>>> Hi,

>>>> I'm wondering why this

>>>> test(<<Field:Len/binary, Rest/binary>>, Len) ->
>>>>    {Len, Field, Rest}.

>>>> does not compile, complaining that "variable 'Len' is unbound", while
>>>> this

>>>> test(<<Field:2/binary, Rest/binary>>, Field) ->
>>>>    {Field, Rest}.

>>>> does. For some reason the compiler doesn't see the Len from the match
>>>> spec in the arguments, but it does see Field. Is that by design?

>>> Yes and a limitation that is being adressed.

>>>> BTW  supplying a variable for Len does work in this case:

>>>> test(Bin, Len) ->
>>>>  <<Field:Len/binary, Rest/binary>> = Bin,
>>>>  {Len, Field, Rest}.

>>> The difference here is that Len is bound when entering the function body
>>> as opposed when it is in the function head.

>>> We have had fierce debates on, among other things, matching behaviors for
>>> Maps (extended frames/hashes) which also have led to redesigning parts how
>>> binary matching is done in function heads. This is currently in the
>>> prototyping stages and it is to early to say to which release this will be
>>> ready.

>>> // Björn-Egil

>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questi...@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions

> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions