<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On 24 Jul 2018, at 15:16, Paul <<a href="mailto:aquagnu@gmail.com">aquagnu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-15">
<p>> that Pandoc supported dynamically loading of extra plugins
on demand.</p>
<p>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.</p></div></blockquote><div>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.</div><div><br></div><div>The Pandoc approach is more like a data pipeline with Pandoc itself at both ends.</div><div><br></div><div>Jeremy </div><br><blockquote type="cite"><div>
<div class="moz-cite-prefix">24.07.2018 09:07, Marc Busqué wrotes:<br>
</div>
<blockquote type="cite" cite="mid:alpine.LNX.2.21.1807240759280.1329@localhost">On Mon, 23
Jul 2018, John Lato wrote:
<br>
<br>
<blockquote type="cite">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
<br>
significant fraction of the user's time, and otherwise the user
experience isn't affected much because the code is basically
interpreted either
<br>
way.
<br>
Haskell is primarily a compiled language. The total download
size probably won't be significantly larger from downloading all
modules. The cost
<br>
of recompiling/dynamically loading plugins will be expensive
(relative to the rest of the user time), and payed with every
execution. Plus it's
<br>
additional work for the developer to set up.
<br>
</blockquote>
<br>
What you say makes a lot of sense in terms of optimization. But,
what
<br>
about extensibility? Take for example the Pandoc package, which
would be
<br>
similar in design of what I'm trying to do. Say I want to add a
<br>
converter to some mark-up format not supported by Pandoc, and that
<br>
Pandoc team doesn't agree to merge my work in its repo or simply I
don't
<br>
have the time to wait until it happens. In this sense, it would be
nice
<br>
that Pandoc supported dynamically loading of extra plugins on
demand.
<br>
<br>
Marc Busqué
<br>
<a class="moz-txt-link-freetext" href="http://waiting-for-dev.github.io/about/">http://waiting-for-dev.github.io/about/</a><br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.</pre>
</blockquote>
<br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Haskell-Cafe mailing list</span><br><span>To (un)subscribe, modify options or view archives go to:</span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a></span><br><span>Only members subscribed via the mailman list are allowed to post.</span></div></blockquote></body></html>