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. 24.07.2018 09:07, Marc Busqué wrotes:

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.

Hmm, so this is easier even. Plugin must have standard interface, available through stdin/stdout/pipes/sockets. Stdin/stdout/stderr is more simple and it's easy to debug (as first version, at least), also can be "mapped" to sockets easy (in inetd-style, for example). "Driver" can looks like "cmd" module in Python (it's better than to use command line arguments, due to length limitation). Even more, it's easy convertable to other protocols/formats which allows to switch to microservice architecture without big effort ;) (I did it in D: communication can be automatically mapped to JSON/XML/Show-Read/etc). It sounds as interesting task. I like Powershell: it extends standard way of Unix scripting languages communicating with strings (like Tcl, shell) to objects instead. So binary protocol can be supported too (MessagePack, BSON, Xdr, etc). It's totally language neutral plugin architecture ;) "Pipelining" can be done in WSGI style - with middleware which can help the "plugging" of protocols :) Dispatching can be achieved with special directory layout/some config file (better). 24.07.2018 10:30, Jeremy O'Donoghue wrotes:

On 24 Jul 2018, at 15:16, Paul mailto:aquagnu@gmail.com> wrote:

...

...

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.

Pandoc plug-ins are separate executables rather than shared libraries. Haskell data types are serialised by Pandoc then de-serialised, modified and re-serialised in each plugin.

The Pandoc approach is more like a data pipeline with Pandoc itself at both ends.

Jeremy

...

24.07.2018 09:07, Marc Busqué wrotes:

...

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.

_______________________________________________ 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.

On Tue, 24 Jul 2018, Paul wrote:

...

you can not load them dynamically, but can turn-on/off dynamically (from a list of pre-installed plugins).

Sorry if it's an obvious question, but, how do you do it? Depends on architecture. Suppose, plugins will be compiled with the application and will be "registered" in some container (list, for example). So, the turn-off will remove them from the list / will mark

24.07.2018 13:29, Marc Busqué wrotes: them with some flag as "disabled". So, your pipeline will skip them. As I understand you have cases: - plugins are DLLs - plugins are statically linked with application but can be disabled individually - plugins are EXEs, so easy can be found/called...

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