I would need to get the position of an element in may array of type Array Int Int. I found the method elemIndex or find to get the position. My problem is, that I don't need the prefix Just 5 for example. So how I only get the number 5 in my example?
The principle
To safely extract a value from a Maybe a value, you can either use pattern matching, like so:
case elemIndex 'C' list of
Just n -> "You can find C at position " ++ show n
Nothing -> "There is no C in the list."
This will return something like
"You can find C at position 2"
or
"There is no C in the list."
depending on whether or not there is a C in the list.
Making it convenient
Of course, this kind of pattern matching is unwieldy to write all the time, so there exists a function called maybe that does pretty much the same thing. If you look at its type signature, you see that
maybe :: b -> (a -> b) -> Maybe a -> b
So it takes a "default value" of type b, and a function from a to b, and will return a b. Whether or not this is the default value depends on whether or not the Maybe a value exists or is Nothing. For example, if you want to check if a list element is allowed entry into an 18+ club, you can do
maybe False (\n -> n >= 18) (elemIndex 'C' list)
This will say False if the index is less than 18 or if the element doesn't exist in the list. If it does exist, it will check if it's greater or equal to 18, and then return True.
Keeping the Just
What I've told you so far is how to get rid of the Just in a safe way. Sometimes, you can't get rid of the Just just yet – sometimes you have no sensible value to return if you have a Nothing on your hands instead of the Just. What you can do then is manipulate values when they are still inside the Just. For example, to subtract 15 from a value inside a just, you just do
fmap (subtract 15) (Just 23)
which will return
Just 8
So you see how fmap sort of takes a Just something value and applies the function to the something part of it, keeping the Just outside. If you would do
fmap (subtract 15) Nothing
it would just keep the Nothing, so the result would be
Nothing
Making it unsafe (kids, don't try this at home!)
Maybe is great because it is an error handling system that forces you to Do Things Right. You just can't ignore the possibility of an error (represented by Nothing.) Another common error handling system is terrible with this. That system is the system of exceptions. Nobody will know if you blatantly ignore that an exception can occur, which is a basis for very unsafe programs.
So you really want to keep the Just until you can toss it away and at the same time replace a potential Nothing value with something sensible.
If you can guarantee that there is no possibility of a Nothing value. If you know for sure that everytime you call elemIndex the element is going to be somewhere in the list, then it's okay to use fromJust. fromJust will blindly try to take a value out of a Just, without giving a dang about what happens if there is no Just there. fromJust will simply explode your program (throw an exception) if something went wrong.
As you understand, you have to use it with much care.
Being unsafe with style
However, as Jedai points out in a comment, even if you shouldn't be able to get a Nothing value, it is better to be explicit about it. Instead of using fromJust, consider doing something like
fromMaybe (error "The input " ++ show list ++ " shouldn't create a Nothing value!")
(elemIndex 'C' list)
which will blow up with a very specific error message, pinpointing where something must have gone wrong.
This is of course the same thing as the pattern match that looks like
case elemIndex 'C' list of
Just n -> n
Nothing -> error "The input " ++ show list ++ " shouldn't create a Nothing value!"
only compacted into the standard fromMaybe function.
Use fromJust from Data.Maybe. Like:
fromJust $ elemIndex 2 [1,2,3,4,5]
And you will get only 1.
But, this will fail if you don't have desired element in the list and you'll get an exception:
*** Exception: Maybe.fromJust: Nothing
Related
I have read some of this post Meaning of Alternative (it's long)
What lead me to that post was learning about Alternative in general. The post gives a good answer to why it is implemented the way it is for List.
My question is:
Why is Alternative implemented for List at all?
Is there perhaps an algorithm that uses Alternative and a List might be passed to it so define it to hold generality?
I thought because Alternative by default defines some and many, that may be part of it but What are some and many useful for contains the comment:
To clarify, the definitions of some and many for the most basic types such as [] and Maybe just loop. So although the definition of some and many for them is valid, it has no meaning.
In the "What are some and many useful for" link above, Will gives an answer to the OP that may contain the answer to my question, but at this point in my Haskelling, the forest is a bit thick to see the trees.
Thanks
There's something of a convention in the Haskell library ecology that if a thing can be an instance of a class, then it should be an instance of the class. I suspect the honest answer to "why is [] an Alternative?" is "because it can be".
...okay, but why does that convention exist? The short answer there is that instances are sort of the one part of Haskell that succumbs only to whole-program analysis. They are global, and if there are two parts of the program that both try to make a particular class/type pairing, that conflict prevents the program from working right. To deal with that, there's a rule of thumb that any instance you write should live in the same module either as the class it's associated with or as the type it's associated with.
Since instances are expected to live in specific modules, it's polite to define those instances whenever you can -- since it's not really reasonable for another library to try to fix up the fact that you haven't provided the instance.
Alternative is useful when viewing [] as the nondeterminism-monad. In that case, <|> represents a choice between two programs and empty represents "no valid choice". This is the same interpretation as for e.g. parsers.
some and many does indeed not make sense for lists, since they try iterating through all possible lists of elements from the given options greedily, starting from the infinite list of just the first option. The list monad isn't lazy enough to do even that, since it might always need to abort if it was given an empty list. There is however one case when both terminates: When given an empty list.
Prelude Control.Applicative> many []
[[]]
Prelude Control.Applicative> some []
[]
If some and many were defined as lazy (in the regex sense), meaning they prefer short lists, you would get out results, but not very useful, since it starts by generating all the infinite number of lists with just the first option:
Prelude Control.Applicative> some' v = liftA2 (:) v (many' v); many' v = pure [] <|> some' v
Prelude Control.Applicative> take 100 . show $ (some' [1,2])
"[[1],[1,1],[1,1,1],[1,1,1,1],[1,1,1,1,1],[1,1,1,1,1,1],[1,1,1,1,1,1,1],[1,1,1,1,1,1,1,1],[1,1,1,1,1,"
Edit: I believe the some and many functions corresponds to a star-semiring while <|> and empty corresponds to plus and zero in a semiring. So mathematically (I think), it would make sense to split those operations out into a separate typeclass, but it would also be kind of silly, since they can be implemented in terms of the other operators in Alternative.
Consider a function like this:
fallback :: Alternative f => a -> (a -> f b) -> (a -> f e) -> f (Either e b)
fallback x f g = (Right <$> f x) <|> (Left <$> g x)
Not spectacularly meaningful, but you can imagine it being used in, say, a parser: try one thing, falling back to another if that doesn't work.
Does this function have a meaning when f ~ []? Sure, why not. If you think of a list's "effects" as being a search through some space, this function seems to represent some kind of biased choice, where you prefer the first option to the second, and while you're willing to try either, you also tag which way you went.
Could a function like this be part of some algorithm which is polymorphic in the Alternative it computes in? Again I don't see why not. It doesn't seem unreasonable for [] to have an Alternative instance, since there is an implementation that satisfies the Alternative laws.
As to the answer linked to by Will Ness that you pointed out: it covers that some and many don't "just loop" for lists. They loop for non-empty lists. For empty lists, they immediately return a value. How useful is this? Probably not very, I must admit. But that functionality comes along with (<|>) and empty, which can be useful.
Is it possible to write functions that returns functions whose signature depends on the arguments to the builder function?
Specifically I am refining an implementation of primitive recursion I wrote. I want to have factory like functions that for numeric parameters generate a function that works on tuples or lists of the length equal to the arguments passed for the numeric parameters. Currently I am handling cases like pr 1 2 [0,5,13], which is an invalid statement from the perspective of primitive recursion, at runtime through Either:
pr :: (Show a) => Int -> Int -> [a] -> Either String a
pr i k args
| 1 <= i && i <= k && length args == k = Right $ args!!(i-1)
| i <= 0 = Left "first argument of pr needs to be greater or equal to 1"
| k < i = Left "first argument of pr needs to be lesser or equal to the second argument"
| length args /= k = Left $ "pr expected "++(show k)++" arguments, got "++(show $ length args)++": pr "++(concat[show i, " ", show k, " ", show args])
But I would like to somehow catch that case at compile time, as from the perspective of the formal system I want to implement with this, this is a compile time error -- passing more arguments to a function than its domain specifies.
Is this somehow possible and if not what would be the correct approach to get compile time errors for what should be invalid statements.
What you want is a sized vector. It is like a list but in addition to the type of its elements, it is also parametrised by type level natural numbers.
sized-vector package on Hackage is what you need. As it happens, the function you're trying to implement is the last function in this library.
Note that every time you call last you will have to prove the compiler that its argument vector is of size at least 1. You can do this by constructing the vector in the source code (for example, the compiler will understand 1 :- 2 :- Nil is of size 2) or if the vector is obtained at runtime perhaps by conversion from a list, you'll have to write a function that either gives a run time error if it has no elements or constructs a vector of size at least one i.e. have the type level size S n for some n.
If you're not familiar with dependently typed programming (a paradigm that includes this and much much more) I suggest you look through some tutorials first. For example, this post is a good example that includes how to implement vectors from scratch and write functions for them.
A word of caution, learning and using dependently typed programming is exciting, addictive, but also time consuming. So if you want to focus on the task at hand, you might like to live with runtime checks for now.
I have a function which will fail if there has being any change on the term/list it is using since the generation of this term/list. I would like to avoid to check that each parameter still the same. So I had thought about each time I generate the term/list to perform a CRC or something similar. Before making use of it I would generate again the CRC so I can be 99,9999% sure the term/list still the same.
Going to a specfic answer, I am programming in Erlang, I am thinking on using a function of the following type:
-spec(list_crc32(List :: [term()]) -> CRC32 :: integer()).
I use term, because it is a list of terms, (erlang has already a default fast CRC libraries but for binary values). I have consider to use "erlang:crc32(term_to_binary(Term))", but not sure if there could be a better approach.
What do you think?
Regards, Borja.
Without more context it is a little bit difficult to understand why you would have this problem, particularly since Erlang terms are immutable -- once assigned no other operation can change the value of a variable, not even in the same function.
So if your question is "How do I quickly assert that true = A == A?" then consider this code:
A = generate_list()
% other things in this function happen
A = A.
The above snippet will always assert that A is still A, because it is not possible to change A like you might do in, say, Python.
If your question is "How do I assert that the value of a new list generated exactly the same value as a different known list?" then using either matching or an actual assertion is the fastest way:
start() ->
A = generate_list(),
assert_loop(A).
assert_loop(A) ->
ok = do_stuff(),
A = generate_list(),
assert_loop(A).
The assert_loop/1 function above is forcing an assertion that the output of generate_list/0 is still exactly A. There is no telling what other things in the system might be happening which may have affected the result of that function, but the line A = generate_list() will crash if the list returned is not exactly the same value as A.
In fact, there is no way to change the A in this example, no matter how many times we execute assert_loop/1 above.
Now consider a different style:
compare_loop(A) ->
ok = do_stuff(),
case A =:= generate_list() of
true -> compare_loop(A);
false -> terminate_gracefully()
end.
Here we have given ourselves the option to do something other than crash, but the effect is ultimately the same, as the =:= is not merely a test of equality, it is a match test meaning that the two do not evaluate to the same values, but that they actually match.
Consider:
1> 1 == 1.0.
true
2> 1 =:= 1.0.
false
The fastest way to compare two terms will depend partly on the sizes of the lists involved but especially on whether or not you expect the assertion to pass or fail more often.
If the check is expected to fail more often then the fastest check is to use an assertion with =, an equivalence test with == or a match test with =:= instead of using erlang:phash2/1. Why? Because these tests can return false as soon as a non-matching element is encountered -- and if this non-match occurs near the beginning of the list then a full traverse of both lists is avoided entirely.
If the check is expected to pass more often then something like erlang:phash2/1 will be faster, but only if the lists are long, because only one list will be fully traversed each iteration (the hash of the original list is already stored). It is possible, though, on a short list that a simple comparison will still be faster than computing a hash, storing it, computing another hash, and then comparing the hashes (obviously). So, as always, benchmark.
A phash2 version could look like:
start() ->
A = generate_list(),
Hash = erlang:phash2(A),
assert_loop(Hash).
assert_loop(Hash) ->
ok = do_stuff(),
Hash = erlang:phash2(generate_list()),
loop(Hash).
Again, this is an assertive loop that will crash instead of exit cleanly, so it would need to be adapted to your needs.
The basic mystery still remains, though: in a language with immutable variables why is it that you don't know whether something will have changed? This is almost certainly a symptom of an underlying architectural problem elsewhere in the program -- either that or simply a misunderstanding of immutability in Erlang.
I'm trying to create a list of unique by appending to a list, but I'm getting this error.
Error: This expression has type 'a list
but an expression was expected of type unit
in_list is a boolean function that checks whether the value is in the list.
if(in_list x seen_list) then print_string("Already found") else seen_list#x in
List.iter uniq check_list;;
It seems like there must be some small syntactic error I need to fix for the append function. Suggestions?
TL;DR: Lists are immutable in OCaml
According to your code, you seem to believe that lists are mutable in OCaml, and they are not. Hence seen_list#x compute a new list but does not change seen_list.
You could change your code to
let uniq seen_list x =
if in_list x seen_list then
(Printf.printf: "uniq: %d: Already seen.\n" x; seen_list)
else x :: seen_list
in
List.fold_left uniq [] check_list
The uniq function maps a list of integers to a list of integers without repetitions, logging the entries it skips.
This code is obviously intended to be learning material, I guess, nevertheless you should be aware that it most likely implements a Shlemiel the painter's algorithm.
This is a type error, not a syntactic error.
An OCaml function must always return a result of the same type. Right now, when the item is in the list your function tries to return a different type than if the item is not in the list.
Specifically, when the item is already there your function calls print_string, which returns (). This is called unit, and is a placeholder representing no interesting value. When the item isn't already there, your function returns a value of type 'a list. Almost certainly what you need to do is to return a list in all cases.
It's hard to say more without seeing more of your code, but the most usual way to handle this situation is to return the old list when the item is already there and a new, longer list when the item isn't already there.
Update
There are many things to fix in this code, but that's the point of the exercise I assume.
Your next problem seems to be that List.iter is an imperative function, i.e., it wants to do something rather than produce a result. Hence the function that it iterates over the list should return unit (described above). You're using the function uniq instead, which returns a list.
If you want to use a higher-order function like List.iter, which is excellent OCaml style, you will need to use a fold (List.fold_left or List.fold_right), whose purpose is to accumulate a result.
I'm very new to Erlang. I tried to find out if a list index is out of bounds (before trying it) so i wanted to do an if clause with something like
if lists:flatlength(A) < DestinationIndex ....
I discovered that those function results cannot be used in if guards so i used case instead. This results in a nested case statement
case Destination < 1 of
true -> {ok,NumberOfJumps+1};
false ->
case lists:flatlength(A) < Destination of
true ->
doSomething;
false ->
case lists:member(Destination,VisitedIndices) of
true -> doSomething;
false ->
doSomethingElse
end
end
end.
I found this bad in terms of readability and code style. Is this how you do things like that in erlang or is there a more elegant way to do this?
Thanks in advance
Before you take the following as some magical gospel, please note that the way this function is entered is almost certainly unidiomatic. You should seek to limit cases way before you get to this point -- the need for nested cases is itself usually a code smell. Sometimes it is genuinely unavoidable, but I strongly suspect that some aspects of this can be simplified way earlier in the code (especially with some more thought given to the data structures that are being passed around, and what they mean).
Without seeing where the variable A is coming from, I'm making one up as a parameter here. Also, without seeing how this function is entered I'm making up a function head, because without the rest of the function to go by its pretty hard to say anything for sure.
With all that said, let's refactor this a bit:
First up, we want to get rid of the one thing we know can go into a guard, and that is your first case that checks whether Destination < 1. Instead of using a case, let's consider that we really want to call two different clauses of a common function:
foo(Destination, NumberOfJumps, _, _) when Destination < 1 ->
{ok, NumerOfJumps + 1};
foo(Destination, _, VisitedIndices, A) ->
case lists:flatlength(A) < Destination of
true -> doSomething;
false ->
case lists:member(Destination,VisitedIndices) of
true -> doSomething;
false -> doSomethingElse
end
end.
Not too weird. But those nested cases that remain... something is annoying about them. This is where I suspect something can be done elsewhere to alleviate the choice of paths being taken here much earlier in the code. But let's pretend that you have no control over that stuff. In this situation assignment of booleans and an if can be a readability enhancer:
foo(Destination, NumberOfJumps, _, _) when Destination < 1 ->
{ok, NumberOfJumps + 1};
foo(Destination, _, VisitedIndices, A) ->
ALength = lists:flatlength(A) < Destination,
AMember = lists:member(Destionation, VisitedIncides),
NextOp =
if
ALength -> fun doSomething/0;
AMember -> fun doSomething/0;
not AMember -> fun doSomethingElse/0
end,
NextOp().
Here I have just cut to the chase and made sure we only execute each potentially expensive operation once by assigning the result to a variable -- but this makes me very uncomfortable because I shouldn't be in this situation to begin with.
In any case, something like this should test the same as the previous code, and in the interim may be more readable. But you should be looking for other places to simplify. In particular, this VisitedIndices business feels fishy (why don't we already know if Destination is a member?), the variable A needing to be flattened after we've arrived in this function is odd (why is it not already flattened? why is there so much of it?), and NumberOfJumps feels something like an accumulator, but its presence is mysterious.
What makes me feel weird about these variables, you might ask? The only one that is consistently used is Destination -- the others are only used either in one clause of foo/4 or the other, but not both. That makes me think this should be different paths of execution somewhere further up the chain of execution, instead of all winding up down here in a super-decision-o-matic type function.
EDIT
With a fuller description of the problem in hand (reference the discussion in comments below), consider how this works out:
-module(jump_calc).
-export([start/1]).
start(A) ->
Value = jump_calc(A, length(A), 1, 0, []),
io:format("Jumps: ~p~n", [Value]).
jump_calc(_, Length, Index, Count, _) when Index < 1; Index > Length ->
Count;
jump_calc(Path, Length, Index, Count, Visited) ->
NewIndex = Index + lists:nth(Index, Path),
NewVisited = [Index | Visited],
NewCount = Count + 1,
case lists:member(NewIndex, NewVisited) of
true -> NewCount;
false -> jump_calc(Path, Length, NewIndex, NewCount, NewVisited)
end.
Always try to front-load as much processing as possible instead of performing the same calculation over and over. Consider how readily we can barrier each iteration behind guards, and how much conditional stuff we don't even have to write because of this. Function matching is a powerful tool -- once you get the hang of it you will really start to enjoy Erlang.