[Haskell-cafe] Imports as first class functions

[Isaac Elliott]

> what would be *really* useful would be if importing was in some sense
“just a function” in IO or some other Monad and therefore also if modules
were represented as some Haskell data structure.

You can do something like this using the GHC API. A program that depends on
the `ghc` library can parse and compile a module, and then look up module
bindings by name and (unsafely) coerce them into normal values. See `hint` (
https://hackage.haskell.org/package/hint) for some inspiration.

I was playing around with this sort of thing because I wanted to use
Haskell modules as plugins for a program that I wrote. I got it working -
the program could load and run the plugin module - but decided to go back
to a fraught stringly-typed interface between two separately compiled
processes.

One reason was that the dynamic loading approach was too slow, and I wasn't
interested in figuring out how to make it faster.

Another reason was that my program is intended for use in certain Haskell
projects, and it's unlikely that the GHC compiler embedded in the program
will match the version that the user has for their project. I didn't want
to allow the user to write code that compiles with their GHC but not when
loaded into my program (e.g. if their GHC version is newer and they use a
new feature).

On Thu, 5 Dec 2024, 03:08 Brandon Allbery, <allbery.b at gmail.com> wrote:

> On Wed, Dec 4, 2024 at 9:31 AM julian getcontented.com.au <
> julian at getcontented.com.au> wrote:
>
>> One of the things a little strange about the programming industry is how
>> quick we are to invent entirely new languages rather than attempt to modify
>> existing ones and beat them into a new more flexible shape so we can
>> shoehorn our new requirements into a more flexible frame. I realise it’s
>> not always possible, but surely if we all got together and worked on it we
>> could do it?
>>
>
> Generally at the price of breaking backward compatibility, which is
> already a major issue with GHC and would get much worse here.
>
>
>> It would be *glorious* if stack (or cabal, or whatever package manager we
>> use) itself were programmable in the sense that it could be called from
>> within Haskell itself using a typed API and data could drive its included
>> packages, and its type could be a function whose range was IO ByteString,
>> providing the compiled binary.
>>
>
> The Cabal library is already largely programmable in this sense, although
> as it drives system tools you have the problem that inputs and outputs are
> disk files coming from or going to those tools. Changing this requires
> changing the system tools, or reimplementing them which would be
> prohibitively difficult and subject to regular breakage.
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20241205/a1071e95/attachment.html>