[erlang-questions] "prefix" ++ Rest = Something

Pierre Fenoll pierrefenoll@REDACTED
Thu Oct 26 15:21:46 CEST 2017


I am not sure I understand your (1): we have been talking about the case
where Prefix is bound, just not with a value known at compile time.

Of course I noticed the :PrefixSize part, I have been writing about it for
3 emails now.
So the :PrefixSize is needed, okay. Why isn't the compiler binding this
variable automatically then?
You know, write:
  <<Prefix/binary, Rest/binary>> = Bla (with Prefix bound)
and the compiler should generate:
  PrefixSize = byte_size(Prefix),
  <<Prefix:PrefixSize/binary, Rest/binary>> = Bla

Obviously the compiler can do this. Now why doesn't it do that already?
Then, let's implement the same matching for lists.
And I believe the fact that a list's length is O(n) will not be an issue:
you can already pattern match lists today.

FYI your Haskell example is also a valid Erlang pattern match.
See http://erlang.org/doc/reference_manual/expressions.html#id80508 section
"Expressions in Patterns".

> Just how much of a problem _is_ this anyway?

I'm repeating the example I gave before:
    <<"{", Name/binary, "}">> = PathToken
With latest Erlang/OTP (20.1) one has to write:
    <<${, Rest/binary>> = PathToken,
    <<$}, Eman/binary>> = binary:reverse(Rest),
    Name = binary:reverse(Eman)

which wastes copying, creates garbage, is of probably worse complexity and
uses a function that doesn't even exist.
Yes, it is maybe time to add binary:reverse/1, from
https://stackoverflow.com/a/43310493/1418165 probably.

Further improvement to pattern matching:
How about allowing matching non-local functions?
  case F of
      fun io:format/2 -> blip();
      fun erlang:display/1 -> blop()
  end
Of course this would only really be matching {M,F,Arity}.



Cheers,
-- 
Pierre Fenoll


On 26 October 2017 at 04:47, Richard A. O'Keefe <ok@REDACTED> wrote:

>
>
> On 26/10/17 3:11 AM, Pierre Fenoll wrote:
>
>> So this can not be described as a pattern.
>>>
>>
>> I'm saying let's fix that.
>>
>> Prefix ++ Rest as a pattern does not need to be calling ++/2.
>> Instead, I am suggesting to allow "partial matches": adding support for
>> these patterns.
>> What makes this hard? Why is this only sugar?
>>
>
> (1) Consider Prefix ++ Rest = List where List has N elements.
>     If Prefix and List are both unbound, there are N+1 solutions.
>     If List is bound, there is at most one solution.
>     If Prefix is bound, there is at most one solution.
>     If Prefix is a list of patterns some of which are unbound,
>     but the length of Prefix is fixed, there is at most one solution.
>
> Why is a similar pattern allowed in binaries but not with lists? (the
>> <<Prefix:PrefixSize/binary, Rest/binary>> pattern)
>>
>
>     Did you notice the :PrefixSize part?  That has to be known.
>     Otherwise it would have the same multiple-solutions problem.
>
> (2) "prefix" ++ Rest as a pattern _doesn't_ call ++/2.
>     It is translated to [$p|[$r|[$e|[$f|[$i|[$x|Rest]]]]]]
>     by the parser.  (As noted above, the _elements_ of the list
>     could perfectly well be any pattern, but the *spine* of the
>     list must be visibly present.)
>
> It's rather like the way Haskell used to allow
>     f 0 = 1
>     f (n+1) = f n * (n+1)
> but did not allow n+m as a pattern.
>
>
> Just how much of a problem _is_ this anyway?
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171026/e1a3ff1c/attachment.htm>


More information about the erlang-questions mailing list