Definition and use of behaviours

Skip to first unread message

Apr 2, 2017, 10:31:16 AM4/2/17
to Lisp Flavoured Erlang
Hi Robert, Duncan,

Can I trouble you for some details on the current and planned (if any) support for definition and use of behaviours?

I note that, as of LFE v1.2.1, the following occur:

- declaring `(behaviour application) in a module but omitting the export or definition of a, say, start/2 raises no compiler warnings;

- defining my own manual that exports a behaviour_info/1 and declaring that behaviour in another module likewise appears to be ignored.

I found two older posts of particular interest:



Duncan McGreggor

Apr 2, 2017, 1:05:53 PM4/2/17
to Lisp Flavoured Erlang
Hey Mike,

Yeah, as far as I know, the latest LFE (dev) still doesn't do compile checks on callback definitions. Robert can correct me if I'm wrong, and that has been added.

However, that's the only limitation I've run into -- you can still use OTP behaviours in LFE, including defining your own. The LFE modules are compiled with the behaviour metadata and thus will work with beam_lib ( This is how the ltest runner checks to see if a test is unit, system, or integration (examining beam chunks to see which behaviour was declared). This is essentially the marker interface pattern.

That being said, I haven't tried to implement a complex behaviour, complete with custom callbacks, in LFE. I don't know what would happen if you tried to port something like gen_event to LFE and if that would work just like the native Erlang gen_event. I suspect it would, though the module callback metadata might be essentially useless. I'm sure Robert knows if a complete behaviour with defined callbacks and a module implementing that behaviour + callbacks would work ... maybe others on this list have worked with complex behaviours implemented purely in LFE ...?


P.S. I just took a quick look at the source code for Erlang's gen_event, and it looks like that could be implemented purely in LFE. The code which manages the handle_event callback is just a message to the gen_event server that is implemented. So as long as your users can look at your LFE code and know which are callbacks -- you can add arbitrary metadata to the module, so your behaviour module could do something like (callback callback-fn-name) -- then when they implement this behaviour, the defining behaviour module will be able to send the appropriate messages to the implementation server. LFE, instead of a signed contract, treats behaviours as a handshake :-) We're so friendly! And trusting!

You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit

Apr 2, 2017, 8:04:29 PM4/2/17
to Lisp Flavoured Erlang
Hi Duncan,

Thanks for the reply!

I've been using custom behaviours for quite some time--long before I started using LFE--along with "umbrella" releases as a means to make dependency inversion explicit and obvious. I hadn't even bothered to confirm (or worry) that LFE was checking them.

However, I've been thinking recently that a (defcallback ...) analogue of -callback() would be nicer than the simplistic (defun behaviour_info (...) ...). Then, it occurred to me that this might all be a ruse in LFE at this point :-)


Robert Virding

Apr 2, 2017, 8:59:54 PM4/2/17
to Lisp Flavoured Erlang
Yes, as Duncan has already said there are no problems in either using behaviours from Erlang and Elixir or defining behaviours in LFE which are usable from E/E. At this level they are just standard Erlang modules with a predefined interface. There are no problems writing them in LFE, you can either build your behaviour on top of gen_server or follow the rules in the Special Processes/sys  and proc_lib section of the documentation There is nothing which causes any complications for LFE.

No, currently the compiler doesn't do any of the standard checking associated with a behaviour declaration. There are no difficulties with it, I just haven't gotten around to it.

Adding something like (defcallback ...) wouldn't be too difficult, we just have to agree to a type syntax as the callback def is really just a type spec of the callback function. And I have to work out what to do with the spec so it is handled in the same way as the Erlang -callback definition. I personally don't have ny problems with (defun bahaviour_info ...). KISS principle. Or perhaps the KICASS principle. (Keep It Clear And Simple Stupid). All I need is an extra K. :-)

Maybe go even further and have a special defbehaviour declaration instead of using defmodule? There is no end to how far you can go. :-)


Apr 2, 2017, 11:13:26 PM4/2/17
to Lisp Flavoured Erlang
Hi Robert,

Thank you as well.

I've no problems with things as they are. Just curious.


Reply all
Reply to author
0 new messages