On 29 Apr 2014, at 19:43, Dawid Loubser wrote:
The primary challenge facing me, is that I am having a hard time
integrating classical, pure functional programming with the ad-hoc
modularity that OSGi enables.
A large part of functional programming is the provability of
correctness etc, and this flies out the window when components can
come and go.
One thing I'm looking at here is using OSGi as ONLY a module system -
ignore components, ignore services - let the types and their visibility
rule.
In a (pure) functional language world where you don't have instances of
services, only functions - or short lived functions via
composition/high-order-function calls etc. I think OSGi ( or any module
system that controls runtime visibility - be that JBoss Modules or
Jigsaw (hahahahahahahaha) ) can work really well.
Lets say:
- Bundle A - functional classes ( haskell style ) or protocols (
clojure )
- Bundle B - data structures
- Bundle C - type class instance definitions of A for structures in B
- Bundle D - functions that operate purely on classes defined in A -
no deps on B or C
- Bundle E - functions that operate on structures from C, calling
functions in D - dependency on C ( or rather, the classes exposed by C)
If you update Bundle C, bundle E would be momentarily unsatisfied until
it restarts and E should then restart and bind to the new classes -
since the majority of functions would be static methods, and for the
most part stateless - the next invocation should get the latest function
definition - unless it's say wrapped inside a monad - but for the extend
of the execution of that monad's life cycle ( which should be rather
short lived ) that should be fine.
The only place where I see some potential problems ( which I'm thinking
about in regards to using clojure in OSGi as well ) is around
Configuration, which at least under Frege could be modelled _easily_ as
wrapping the required functions as returning `State BundleContext a` - a
function that requires access to the BundleContext to order to lookup
configuration.
Reusing `State BundleContext a` would also allow you access to existing
OSGi services in a fairly generic fashion, maybe returning an `ErrorT`
[1] rather than `a` directly to handle the fact that a) configuration or
b) service might not exist.
Wish I had some more time to think about, and play with this actually.
Mark
[1]
https://hackage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-Error.html
