[erlang-questions] Function Dependency
Tue Aug 21 12:46:39 CEST 2012
I don't know of any such function. You might get by with:
> listing all modules in your path with code:get_path().
> Filtering out the ones which you don't want (i.e. the ones which come
with the Erlang distribution). Probably you'd use the $ERL_TOP environment
variable if it's set or something.
> Listing the beams in these directories and taking it from there
basically.. i.e. you could then check using ModuleName:module_info(exports)
or something... it's a DIY solution off the top of my head but it should
Of course, encapsulating the logic to handle gen_server messages in
different functions and then delegating to them is a good idea... I just
wanted to point out that there **might** be a reason to get access to one
or more of a function's clauses (and that parse_transform/2 is probably the
way to go about it).
On 21 August 2012 08:23, Tyron Zerafa <> wrote:
> Thanks for your answers, I tried using xref and it is working
> perfectly, I am able to get both the local and remote functions which I am
> calling from a specific function.
> I need to extract the function body for the following reasons. I need to
> transfer only the code that a function makes use of between nodes, nothing
> more. Xref is giving me the signature of all those functions that I need.
> Now, I want to use these signatures to extract the remaining body of the
> Another short question, is there any way in which I can differentiate
> whether a function comes from an Erlang release or not? Thus, if for
> example I ask is_native(io_lib,format,2) - > true,
> otherwise is_native(MyModule, MyFunction,0) -> false. I do not need to
> transfer functions which are native to Erlang and which can be found on any
> Erlang node.
> Thanks again for your help
> On Tue, Aug 21, 2012 at 12:58 AM, Richard O'Keefe <>wrote:
>> On 21/08/2012, at 9:48 AM, Justin Calleja wrote:
>> > Here's one instance that comes to mind with regards to wanting part of
>> a function definition (i.e. just some of it's clauses):
>> > When implementing a gen_server you handle synchronous requests using
>> handle_call/3. You might just want the implementation of handle_call/3
>> which deals with certain messages.
>> Yes, but that part
>> - might be more than one clause
>> - which need not be contiguous in the function
>> - and some or all of them might be shared with the handling
>> of other messages.
>> It is possible to deliberately construct a function as a
>> collection of clauses with small non-overlapping heads that
>> simply redirect to other functions, so that it would make
>> sense to extract part of _that_ function, and you would
>> do so *not* by extracting the clause but by simply picking
>> up the entire function that it delegates to.
>> That doesn't mean it makes sense to extract part of a
>> function that wasn't written to be treated that way.
> Best Regards,
> Tyron Zerafa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions