[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