I wanted to add some more symbols to my Erlang library. Example
For a matrix library A**B could mean matrix multiplication etc.
I could not find any help for the same.
Also anyone knows how to apply functions like + - or % using erlang:apply()
You can use any atom as function name. If you have specail symbols in atom you have to use its quoted form '**':
-module(operator).
-export(['**'/2]).
'**'(A, B) ->
{'**', A, B}.
There is no syntactic sugar to use such operators though. All the default operators are functions defined in module erlang and can be accessed like that:
1> operator:'**'(a, b).
{'**',a,b}
2> F0 = fun operator:'**'/2.
#Fun<operator.**.2>
3> F0(c, d).
{'**',c,d}
4> F1 = fun erlang:'+'/2.
#Fun<erlang.+.2>
5> F1(1, 2).
3
6> F2 = fun erlang:'rem'/2.
#Fun<erlang.rem.2>
7> F2(5, 3).
2
If you really, really want this you can use a parse transform but your code has to be syntactically correct before the transform. So for example your parse transform can rewrite A *_* B into exp(A, B) because A *_* B will be parsed as something like (A * _) * B. However you will not be able to transform A ** B.
Also, using parse transforms for something so frivolous is a really bad idea.
Related
How to use a three parametered infix operator?
Eg.: base function is
let orElse labelFunc p1 p2 = {...} and operator let ( <|> ) = orElse
Now, for non-infix version this works nicely:List.reduce ((<|>) labelFunc) parserList.
Can I use it somehow still "infixing"? eg.: (p1 (<|> labelFunc) p1) does not work nor any other combination, other than using the non-infix version here as well.
First of all, I think it's best to restrict the number of custom operators you're using in your code, because custom operators make F# code hard to read. F# lets you define custom operators, but it's not particularly designed to make this a great experience - it makes sense for some small domain-specific languages (like parser combinators), but not much else.
So, while I do not recommend using this, there is a weird trick that you can use to write something like p1 (<op> l) p2, which is to make <op> infix and replace the parentheses with two more custom operators:
let (</) a b = a, b
let (/>) c d = c, d
let (!) f = f
1 </ !10 /> 2
This sample just produces a tuple with all three arguments, but if you implement your logic in the </ operator, it will actually do something like what you want. But as I said, I would not do this :-).
I don't believe there is any good way to achieve that. Once you have a parenthesized expression it won't be parsed as an operator - even 1 (+) 1 doesn't work.
I'm learning Erlang and came across Pattern Matching.
Could someone kindly explain to me what is Pattern Matching using a simple explanation.
An explanation in which anybody could understand.
I have read multiple sources but still can't grasp the concept.
Could someone kindly explain to me what is Pattern Matching using a
simple explanation. An explanation in which anybody could understand.
Pattern matching is how assignment is instigated in erlang. In other languages, the = sign is the assignment operator, e.g. x = 10. However, in erlang, the = sign is the pattern match operator. When erlang sees an = sign, it looks at the term on the right hand side of the = sign, then tries to give values to the variables on the left hand side of the equals sign, so that both sides of the = sign are identical, i.e. they match.
In the simple case, e.g. X = 1, it looks like the = sign performs assignment in erlang. And in fact, X will have the value 1 after that statement is evaluated. However, you can't write the following in other languages:
{Y, 10} = {20, 10}
In other languages you can't have constants on the left hand side of the assignment operator. In erlang, however, specifying constants on the left of the pattern match operator is perfectly normal. After that statement is evaluated, Y will have the value 20 because in order for both sides of the = sign to be identical, erlang has to assign the value 20 to Y.
How does erlang perform that assignment? It doesn't really matter, but you can think of the assignment operator in erlang as the three characters !*!. When erlang sees the pattern match operator in the example above, in order to get things to match up, erlang uses the assignment operator !*! to assign the value 20 to Y, i.e. Y !*! 20.
When you write = in erlang, you are asking, "Please try to get these things to match!". The knock on effect is that erlang will perform some assignments (!*!) to make both sides match. You can't do assignment directly yourself, all you can do is ask erlang to make things match. If that is too confusing, then just think of the pattern match operator as a trick assignment operator, which is more powerful than the assignment operator in other languages. It doesn't matter what you call the = sign in erlang, you just need to know how it works.
In erlang, pattern matching can be used in a lot of different ways:
1) To extract positional values from a data structure:
15> [X, {Y, _}] = [10, {1, hello}].
[10,{1,hello}]
16> X.
10
17> Y.
1
2) To determine which function clause executes in a function definition:
my.erl:
go(X, hello) ->
io:format("Do stuff: ~w~n", [X*2]);
go(X, goodbye) ->
io:format("Do other stuff: ~w~n", [X-2]);
go(_, _) ->
io:format("Okay.~n").
In the shell:
7> c(my).
my.erl:2: Warning: export_all flag enabled - all functions will be exported
{ok,my}
8> my:go(3, 4).
Okay
ok
9> my:go(2, goodbye).
Do other stuff: 0
ok
10> my:go(10, hello).
Do stuff: 20
ok
In the first function call, erlang performs the following pattern match:
{X, hello} = {3, 4}
...which fails because no value that erlang can assign(!*!) to X will make both sides match. So, erlang continues on to the next function clause and performs the match:
{X, goodbye} = {3, 4}
which also fails; finally the third function clause matches, so the statements in the body of that function clause execute.
3) Case statements, list comprehensions, etc.
Consider this example of pattern matching in a function:
Eshell V8.2.1 (abort with ^G)
1> F = fun(1, X) -> "hello f1";
1> (2, X) -> "hello f2"
1> end.
#Fun<erl_eval.12.52032458>
2> F(1, 33).
"hello f1"
3> F(2, some_token).
"hello f2"
4> F(3, "...").
** exception error: no function clause matching erl_eval:'-inside-an-interpreted-fun-'(3,"...")
5>
The pattern matching against the first argument of function F enables to execute a branch of code or another.
Pattern matching is a way to:
guarantee that some conditions are met
have the code go into some specific branches (like if-then-else)
raise an error if an execution path is invalid
See also the official documentation page:
http://erlang.org/doc/reference_manual/patterns.html
I have already done some searches, and this question is a duplicate of another post. I am posting this just for future reference.
Is it possible to define SUMPRODUCT without explicitly using variable names x, y?
Original Function:
let SUMPRODUCT x y = List.map2 (*) x y |> List.sum
SUMPRODUCT [1;4] [3;25] // Result: 103
I was hoping to do this:
// CONTAINS ERROR!
let SUMPRODUCT = (List.map2 (*)) >> List.sum
// CONTAINS ERROR!
But F# comes back with an error.
I have already found the solution on another post, but if you have any suggestions please let me know. Thank you.
Function composition only works when the input function takes a single argument. However, in your example, the result of List.map2 (*) is a function that takes two separate arguments and so it cannot be easily composed with List.sum using >>.
There are various ways to work around this if you really want, but I would not do that. I think >> is nice in a few rare cases where it fits nicely, but trying to over-use it leads to unreadable mess.
In some functional languages, the core library defines helpers for turning function with two arguments into a function that takes a tuple and vice versa.
let uncurry f (x, y) = f x y
let curry f x y = f (x, y)
You could use those two to define your sumProduct like this:
let sumProduct = curry ((uncurry (List.map2 (*))) >> List.sum)
Now it is point-free and understanding it is a fun mental challenge, but for all practical purposes, nobody will be able to understand the code and it is also longer than your original explicit version:
let sumProduct x y = List.map2 (*) x y |> List.sum
According to this post:
What am I missing: is function composition with multiple arguments possible?
Sometimes "pointed" style code is better than "pointfree" style code, and there is no good way to unify the type difference of the original function to what I hope to achieve.
I am trying to turn a tuple of the form:
{{A,B,{C,A,{neg,A}}},{A,B,{neg,A}}}
Into
{{A,B,C,A,{neg,A}},{A,B,{neg,A}}
I'm quite new to Erlang so I would appreciate any hints. It makes no difference if the final structure is a list or a tuple, as long as any letter preceded by neg stays as a tuple/list.
A simple solution:
convert({{A,B,{C,D,E}},F}) -> {{A,B,C,D,E},F}.
If why this works is puzzling, consider:
1> YourTuple = {{a, b, {c, a, {neg, a}}}, {a, b, {neg, a}}}.
{{a,b,{c,a,{neg,a}}},{a,b,{neg,a}}}
2> Convert = fun({{A,B,{C,D,E}},F}) -> {{A,B,C,D,E},F} end.
#Fun<erl_eval.6.54118792>
3> Convert(YourTuple).
{{a,b,c,a,{neg,a}},{a,b,{neg,a}}}
The reason this happens is because we are matching over entire values based on the shape of the data. That's the whole point of matching, and also why its super useful in so many cases (and also why we want to use tuples in more specific circumstances in a language with matching VS a language where "everything is an iterable"). We can substitute the details with anything and they will be matched and returned accordingly:
4> MyTuple = {{"foo", bar, {<<"baz">>, balls, {ugh, "HURR!"}}}, {"Fee", "fi", "fo", "fum"}}.
{{"foo",bar,{<<"baz">>,balls,{ugh,"HURR!"}}},
{"Fee","fi","fo","fum"}}
5> Convert(MyTuple).
{{"foo",bar,<<"baz">>,balls,{ugh,"HURR!"}},
{"Fee","fi","fo","fum"}}
Why did this work when the last element of the top-level pair was so different in shape than the first one? Because everything about that second element was bound to the symbol F in the function represented by Convert (note that in the shell I named an anonymous function for convenience, this would be exactly the same as using convert/1 that I wrote at the top of this answer). We don't care what that second element was -- in fact we don't want to have to care about the details of that. The freedom to selectively not care about the shape of a given element of data is one of the key abstractions we use in Erlang.
"But those were just atoms 'a', 'b', 'c' etc. I have different things in there!"
Just to make it look superficially like your example above (and reinforce what I was saying about not caring about exactly what we bound to a given variable):
6> A = 1.
1
7> B = 2.
2
8> C = 3.
3
9> AnotherTuple = {{A, B, {C, A, {neg, A}}}, {A, B, {neg, A}}}.
{{1,2,{3,1,{neg,1}}},{1,2,{neg,1}}}
10> Convert(AnotherTuple).
{{1,2,3,1,{neg,1}},{1,2,{neg,1}}}
Needing to do this is not usually optimal, though. Generally speaking the other parts of the program that are producing that data in the first place should be returning useful data types for you. If not you can certainly hide them behind a conversion function such as the one above (especially when you're dealing with APIs that are out of your control), but generally speaking the need for this is a code smell.
And moving on
The more general case of "needing to flatten a tuple" is a bit different.
Tuples are tuples because each location within it has a meaning. So you don't usually hear of people needing to "flatten a tuple" because that fundamentally changes the meaning of the data you are dealing with. If you have this problem, you should not be using tuples to begin with.
That said, we can convert a tuple to a list, and we can check the shape of a data element. With these two operations in hand we could write a procedure that moves through a tuplish structure, building a list out of whatever it finds inside as it goes. A naive implementation might look like this:
-module(tuplish).
-export([flatten/1]).
-spec flatten(list() | tuple()) -> list().
flatten(Thing) ->
lists:flatten(flatten(Thing, [])).
flatten(Thing, A) when is_tuple(Thing) ->
flatten(tuple_to_list(Thing), A);
flatten([], A) ->
lists:reverse(A);
flatten([H | T], A) when is_tuple(H) ->
flatten(T, [flatten(H) | A]);
flatten([H | T], A) when is_list(H) ->
flatten(T, [flatten(H) | A]);
flatten([H | T], A) ->
flatten(T, [H | A]).
Keep in mind that after several years of writing Erlang code I have never needed to actually do this. Remember: tuples mean something different than lists.
All that said, the problem you are facing is almost certainly handled better by using records.
Which of theese two alternatives do you find yourself using most often, and which is more "idiomatic"?
f arg (obj.DoStuff())
f arg <| obj.DoStuff()
Overall, I don't know that one or the other is more idiomatic.
Personally, the only time I use <| is with "raise":
raise <| new FooException("blah")
Apart from that, I always use parens. Note that since most F# code uses curried functions, this does not typically imply any "extra" parens:
f arg (g x y)
It's when you get into non-curried functions and constructors and whatnot that it starts getting less pretty:
f arg (g(x,y))
We will probably at least consider changing the F# languages rules so that high-precedence applications bind even more tightly; right now
f g()
parses like
f g ()
but a lot of people would like it to parse as
f (g())
(the motivating case in the original question). If you have a strong opinion about this, leave a comment on this response.
Because type inference works from left to right, a bonus of using |> is that it allows F# to infer the type of the argument of the function.
As a contrived example,
[1; 2; 3] |> (fun x -> x.Length*2)
works just fine, but
(fun x -> x.Length*2) [1; 2; 3]
complains of "lookup on object of indeterminate type".
I use () much much more often, but thats just preference, I'm pretty sure that <| is more idomatic, but I use () by habit.
Whenever possible, I much prefer |> because it reads from left to right.