pid(A, B, C) can generate a pid <A.B.C>, how can I get A, B and C from a pid?
You can use pid_to_list, Erlang doc, but you probably shouldn't since it is generally a bad practice.
Related
I'm attempting to use Railway Oriented Programming principals http://fsharpforfunandprofit.com/rop/ and this http://indiedevspot.azurewebsites.net/2015/01/20/two-track-coding-rop-for-dummies-part-2/ for reference
I have successfully implemented this for most of the codebase, except now we are getting to putting items into SQL and wish to use ROP for validation of those types. The typical pattern is
Figure 1:
let createSomething a b c = {A = a; B = b; C = c}
let createValidSomething so =
createSomething
<!> validateFunction1 so.param1
<*> validateFunction2 so.param2
<*> ...so forth and so on
You will notice that createSomething is a function that returns a record type instantiation a -> b -> c -> a' -> b' -> c'
The SQL Type providers return a mutable type (non record). Lets look at my attempt to build a similar createSomething function
Figure 2:
let createSQS(a, b, c, d, e, f, g) =
let sqs = context.``[dbo].[Something]``.Create(a, b, c, d, e, f, g)
sqs
At this point, we know this already will not work, we have a->b->c->d->e->f->g->context.[dbo].[Something].Entity
I know I can have an intermediary record type and follow ROP principals, match on success/failure and then create my object off of the already validated. But does that not seem like too many steps?
Does anybody know of a good pattern for this? Ideally we could have a function similar to Figure1 that generates a Record Type that is compatible with the Type Providers.
I'm open to trying things and hanging out on Skype :).
Should your function createSQS not be better like this:
let createSQS a b c d e f g =
context.``[dbo].[Something]``.Create(a, b, c, d, e, f, g)
This one would have the needed signature of a->b->c->d->e->f->g->context.[dbo].[Something].Entity
So we came up with an answer at our dev meeting, and decided that we in fact WANT to execute each part in its own function. For the inner binds we invented our own operator; similar to plus (&&&) (which I will blog about on my site www.indiedevspot.com) and at the top level we ran with a normal bind.
Our top level code looks like this:
[<HttpPost>]
x.member Add(sa:Something) =
sa|>ValidateSomething
>>= converttoSSA
>>= persistSSA
We decided to separate the concerns due to independent testability of validation, conversion and persistence. The theory is that functional composition if made up of functions that are guaranteed to work, is itself inherently guaranteed to work (or have a much better chance).
If we went with the proposed method (which we have not yet solved), we would be mixing concerns of creation, validation and conversion. That would also end up creating an additional record type which was un-necessary.
I'm a completely new to erlang. As an exercise to learn the language, I'm trying to implement the function sublist using tail recursion and without using reverse. Here's the function that I took from this site http://learnyousomeerlang.com/recursion:
tail_sublist(L, N) -> reverse(tail_sublist(L, N, [])).
tail_sublist(_, 0, SubList) -> SubList;
tail_sublist([], _, SubList) -> SubList;
tail_sublist([H|T], N, SubList) when N > 0 ->
tail_sublist(T, N-1, [H|SubList]).
It seems the use of reverse in erlang is very frequent.
In Mozart/Oz, it's very easy to create such the function using unbound variables:
proc {Sublist Xs N R}
if N>0 then
case Xs
of nil then
R = nil
[] X|Xr then
Unbound
in
R = X|Unbound
{Sublist Xr N-1 Unbound}
end
else
R=nil
end
end
Is it possible to create a similar code in erlang? If not, why?
Edit:
I want to clarify something about the question. The function in Oz doesn't use any auxiliary function (no append, no reverse, no anything external or BIF). It's also built using tail recursion.
When I ask if it's possible to create something similar in erlang, I'm asking if it's possible to implement a function or set of functions in erlang using tail recursion, and iterating over the initial list only once.
At this point, after reading your comments and answers, I'm doubtful that it can be done, because erlang doesn't seem to support unbound variables. It seems that all variables need to be assigned to value.
Short Version
No, you can't have a similar code in Erlang. The reason is because in Erlang variables are Single assignment variables.
Unbound Variables are simply not allowed in Erlang.
Long Version
I can't imagine a tail recursive function similar to the one you presenting above due to differences at paradigm level of the two languages you are trying to compare.
But nevertheless it also depends of what you mean by similar code.
So, correct me if I am wrong, the following
R = X|Unbound
{Sublist Xr N-1 Unbound}
Means that the attribution (R=X|Unbound) will not be executed until the recursive call returns the value of Unbound.
This to me looks a lot like the following:
sublist(_,0) -> [];
sublist([],_) -> [];
sublist([H|T],N)
when is_integer(N) ->
NewTail = sublist(T,N-1),
[H|NewTail].
%% or
%%sublist([H|T],N)
%% when is_integer(N) -> [H|sublist(T,N-1)].
But this code isn't tail recursive.
Here's a version that uses appends along the way instead of a reverse at the end.
subl(L, N) -> subl(L, N, []).
subl(_, 0, Accumulator) ->
Accumulator;
subl([], _, Accumulator) ->
Accumulator;
subl([H|T], N, Accumulator) ->
subl(T, N-1, Accumulator ++ [H]).
I would not say that "the use of reverse in Erlang is very frequent". I would say that the use of reverse is very common in toy problems in functional languages where lists are a significant data type.
I'm not sure how close to your Oz code you're trying to get with your "is it possible to create a similar code in Erlang? If not, why?" They are two different languages and have made many different syntax choices.
If process A spawn_link()'s process B and then process B spawn()'s process C, is the only way for process A to catch an error in process C if we replace "spawn()" for "spawn_link()" in process B?
I believe if this isn't replaced, process A will only know if process B dies?
When process B spawns process C, it basically forgets about it; in this case, if C is dying, process B will have no idea about it. If process B spawns process C using spawn_link, process C will be linked to B as child (C) - parent (B): if C dies, B will be notified and depending on the implementation, it can die (A will be notified) or survive further.
I want to test whether two languages have a string in common. Both of these languages are from a subset of regular languages described below and I only need to know whether there exists a string in both languages, not produce an example string.
The language is specified by a glob-like string like
/foo/**/bar/*.baz
where ** matches 0 or more characters, and * matches zero or more characters that are not /, and all other characters are literal.
Any ideas?
thanks,
mike
EDIT:
I implemented something that seems to perform well, but have yet to try a correctness proof. You can see the source and unit tests
Build FAs A and B for both languages, and construct the "intersection FA" AnB. If AnB has at least one accepting state accessible from the start state, then there is a word that is in both languages.
Constructing AnB could be tricky, but I'm sure there are FA textbooks that cover it. The approach I would take is:
The states of AnB is the cartesian product of the states of A and B respectively. A state in AnB is written (a, b) where a is a state in A and b is a state in B.
A transition (a, b) ->r (c, d) (meaning, there is a transition from (a, b) to (c, d) on symbol r) exists iff a ->r c is a transition in A, and b ->r d is a transition in B.
(a, b) is a start state in AnB iff a and b are start states in A and B respectively.
(a, b) is an accepting state in AnB iff each is an accepting state in its respective FA.
This is all off the top of my head, and hence completely unproven!
I just did a quick search and this problem is decidable (aka can be done), but I don't know of any good algorithms to do it. One is solution is:
Convert both regular expressions to NFAs A and B
Create a NFA, C, that represents the intersection of A and B.
Now try every string from 0 to the number of states in C and see if C accepts it (since if the string is longer it must repeat states at one point).
I know this might be a little hard to follow but this is only way I know how.
I've read through all the documentation, and most of the source of LFE. All the presentations emphasize basic lisp in traditional lisp roles - General Problem Solving, Hello world and syntax emulating macros.
Does anyone know how LFE handles messaging primitives? To specify a more precise question, how would you express this erlang:
A = 2,
Pid = spawn(fun()->
receive
B when is_integer(B) -> io:format("Added: ~p~n",[A+B]);
_ -> nan
end
end),
Pid ! 5.
And then, you know, it mumbles something about having added up some numbers and the answer being 7.
I'm not an LFE user, but there is a user guide in the source tree. From reading it I would guess it is something like this:
(let ((A 2))
(let ((Pid (spawn (lambda ()
(receive
(B (when (is_integer B))
(: io format "Added: ~p~n" (list (+ A B))))
(_ nan))))))
(! Pid 5)))
But I'm very likely to have made a mistake since I haven't even evaluated it in LFE.
Some questions of mine:
Is there a LET* form or is it behaving like one already?
Are guards called the more lispy is-integer and not is_integer as I wrote?
There is a serious lack of examples in the LFE release, all contributions are welcome.
Christian's suggestion is correct. My only comment is that there is no need to have capitalized variable names, it is not wrong, but not necessary.
The LFE let is a "real" let in which the variable bindings are visible first in the body. You can use patterns in let. There is also a let* form (macro actually) which binds sequentially.
No, I have so far kept all the Erlang core function names just as they are in vanilla erlang. It is definitely more lispy to use -instead of _ in names, but what do you do with all the other function names and atoms in OTP? One suggestion is to automatically map - in LFE symbols to _ in the resultant atoms, and back again going the other way of course. This would probably work, but would it lead to confusion?
I could then have a behaviour module looking like:
(defmodule foo
(export (init 1) (handle-call 2) (handle-cast 2) (handle-info 2) ...)
(behaviour gen-server))
(defun handle-call ...)
(defun handle-cast ...)
etc ...
But I am very ambivalent about it.