<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>One compromise GHC could make would be abstract the notion of
module from the Haskell source (multiple modules per file, no file
involved at all), but ultimately as Brandon says, the file system
has to get involved for the linker, so the concept of a module
needs to remain compatible with the action of writing it as a
file. <br>
</p>
<div class="moz-cite-prefix">Le 02/12/2024 à 10:36, Brandon Allbery
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAKFCL4U=UMv565MjyqJQtwT=SeKyJnrOGnKgD1QCNcFurTFZvA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">As long as we're using system tools for assembling
and linking, we must abide by their constraints. Not using them
isn't really viable; linking in particular is a nightmare. The
bytecode interpreter has a partial linker because it can't use
the system one, and it's easily the nastiest part of ghc. It's
also completely nonportable, by definition: every target has its
own notion of what relocations are available and how they work.</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2024 at 4:16 AM
julian <a href="http://getcontented.com.au"
moz-do-not-send="true">getcontented.com.au</a> <<a
href="mailto:julian@getcontented.com.au"
moz-do-not-send="true" class="moz-txt-link-freetext">julian@getcontented.com.au</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In
a recent project that compiles Haskell source from data (ie of
type Text from the module Data.Text), it would be useful to be
able to decouple the dependency between GHC’s notion of where
modules are and the file system. This doesn’t seem to be
programmatically controllable.<br>
<br>
How tenable is this? Would it be useful for anyone else to
have compilation itself be more first class in the language?
If I think about languages such as LISP/Racket/Clojure,
there’s a certain flexibility there that Haskell lacks, but
it’s not apparent why, other than historical reasons? Would
this imply changing compiling and linking into a different
Monad than IO?<br>
<br>
At the moment to compile some source that exists in Text, my
system has to write a bunch of temp files including the Text
that contains the main module, and then put other modules in
directories named a certain way, run the compiler across them
via some exec command to call GHC or stack externally, then
read the resulting executable back off disk to store it in its
final destination.<br>
<br>
It might be useful to be able to do this from within Haskell
code directly, partly similarly to how the hint library works.
Though, in this case it would almost certainly also require
being able to have two versions of GHC loaded at once, which
would also imply being able to simultaneously have multiple or
different versions of libraries loaded at once, too, and
possibly also just from data, ie not from disk. It feels like
a massive, massive project at that point, though, like we’d be
putting an entire dependency system into a first-class
programmable context. I’m still interested in what folks think
about these ideas, though, event though we this may never
eventuate.<br>
<br>
Does it seem to anyone else like abstracting the library and
module-access capabilities of compilation so that it’s
polymorphic over where it gets its data from might be useful?
Is this just ridiculous? Does this step into Backpack's
territory? From memory, the Haskell report doesn’t specify
that modules necessarily need to be tied to the file system,
but I think GHC imposes one file per module and that it be one
the FS.<br>
<br>
Julian<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to
post.</blockquote>
</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>brandon s allbery kf8nh</div>
<div><a href="mailto:allbery.b@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">allbery.b@gmail.com</a></div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
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>
<pre class="moz-signature" cols="72">--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: <a class="moz-txt-link-freetext" href="https://glitchbra.in">https://glitchbra.in</a>
RUN: BSD</pre>
</body>
</html>