> that Pandoc supported dynamically loading of extra plugins on demand.

It means .dll/.so. But also there are applications with pre-built "plugins" - you can not load them dynamically, but can turn-on/off dynamically (from a list of pre-installed plugins). It's useful too.

On Mon, 23 Jul 2018, John Lato wrote:

I think you're attempting to optimize the wrong thing. In a dynamic language like Ruby, this approach makes sense because download times are a
significant fraction of the user's time, and otherwise the user experience isn't affected much because the code is basically interpreted either
way.
Haskell is primarily a compiled language. The total download size probably won't be significantly larger from downloading all modules. The cost
of recompiling/dynamically loading plugins will be expensive (relative to the rest of the user time), and payed with every execution. Plus it's
additional work for the developer to set up.

What you say makes a lot of sense in terms of optimization. But, what
about extensibility? Take for example the Pandoc package, which would be
similar in design of what I'm trying to do. Say I want to add a
converter to some mark-up format not supported by Pandoc, and that
Pandoc team doesn't agree to merge my work in its repo or simply I don't
have the time to wait until it happens. In this sense, it would be nice
that Pandoc supported dynamically loading of extra plugins on demand.

Marc Busqué
http://waiting-for-dev.github.io/about/

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.