Discussion on polymorphism idioms in LFE

[oubiwann]

There was a blog post written about this topic here:

• http://blog.lfe.io/design/2015/07/11/1720-towards-multi-methods-in-lfe/

Code for exploring polymorphism continues to grow/adapt here:

• https://github.com/lfex/los/blob/master/examples/no-macros/polymorph.lfe

This issue was opened in particular due to a tantalizing comment made by @rvirding on the LFE mail list -- he may have some nice ideas for better LFE idioms:

• https://groups.google.com/d/msg/lisp-flavoured-erlang/nvAAOwE62n8/KEiZH7HbBAAJ

[hdurer]

A discussion of Elixir's protocols would also be nice.
Except for the actual implementation I cannot find much about how it is implemented and from what I understand, it is fairly inefficient but the its true extensibility is quite interesting.

[rvirding]

When will I learn to keep my mouth shut? :-)
In all these discussions I have absolutely no idea how clojure does it.

My thought was just that in one way this doesn't really give you that much. You may be splitting the handling into separate functions based on the type but they are still all in one module. At least in you example. Wouldn't it be better to break the various types into separate modules instead? Your dispatch functions would then become something like:

(defun area
  (((= `#m(type ,type) args))
   (dispatch 'area type args)))

(defun dispatch (fname type args)
   (call type fname args))

I think you should leave the type so you always know what it is you are working with. You would then have a module for each type each containing a set of functions for that type. There would be a circle/rectangle/triangle/... module each with functions area/perimeter/... I think that adding a new shape would then be much easier as you just need to add a new module for that shape and not have to touch anything else.

This is pretty much how flavors does it. Each flavor is semi independant and only defines which other flavors it depends on then when you create the first flavor you will get all the flavors that are required. Pretty much like deps in rebar. The main idea is that you define each separately.

Again I have no idea how clojure does it and if this is where you were intending to go.

[rvirding]

Check out the shapes example in flavors which is sort of a proto example of this. Flavors instances aren't the same as this and are heavier things and very objecty and they use processes. I was sort of testing something like this in my first version of flavors but I felt that flavor instances would be better as processes.

[rvirding]

I am looking at elixir protocols and will report back on them later. Know how their structs work though.

[oubiwann]

Oh, that's a great idea.

I'm not too concerned about how Clojure does things, especially since our other conversations on this topic. I'm actually much more interested in how to make an analogously good user experience which is tailored to the Erlang VM and LFE than duplicate the Clojure process with syntactic sugar.

Again, not that the Clojure is bad (as I've said before, I love the language). Rather, the user experience in Clojure is based on building a Lisp around a completely different VM than the one that we're working with :-) Different benefits and different problems!

You're idea is a good one, since it's simple, elegant, follows a similar pattern with BEAM languages (it's close to how behaviours are used), and isn't trying to be like something else :-)

I'll take a look at the Flavors examples ... and for this purposes of an example file like this, the multi-module feature will be very useful :-)