Suppose the following:
I have a type called World representing some simulation state. I also have this type synonym:
type Update = World -> World
Is Haskell capable of serializing the Update type such that it can be passed over the network? Or is there any other means of doing so? Maybe I'm not looking for a serialization of the code's logic so much, as some kind of pointer or identifier that can be read on the other end. Both the sending and receiving process are running the same Haskell program.
The distributed-process package is exactly what you described. Since each program already has the same set of functions a pointer to the function is passed from one process to another. There has been mentioned serialization of the function as a potential future goal but is sound like it might take a change to GHC. The github page is a good resource for what backends exist. The github-pages look very nice with some examples, but I did not know about it until a moment ago.
The few Haskell Parallel digests around issue 11 is where I remember learning the most. Definitely take some time to explore github-pages I know I will be.
If I remember correctly there are simple examples in the hackage package or on the github repo exploring work stealing vs work sharing and similar strategies.
I suggest making a DSL data structure. Sadly Haskell does not have lisp's runtime compilation features, but it should be sufficient.
Related
I want to produce revised, fresh versions of this diagram, which appears in the Haskell98 standard:
In 2019 I will do this by generating a description of the graph I want, and feeding it to Graphviz. A proof-of-concept implementation I did yesterday, told only that there is something called Monad, can automatically produce this diagram:
The proof-of-concept program is rather awful, because the way it traverses the graph is by sending :info commands to GHCi and attempting to parse the output. I am not interested in pushing this approach any further.
The right way to do this is to figure out how GHC represents the class and instance information internally, then use its API to interrogate those data structures directly.
I have spent quite some time looking around in the GHC API documents but I have not found the entry points I need.
I think I want to ask GHC for a list of the names of all the typeclass and instance information currently in scope, and for a description of the constraints for each one.
What are good ways to proceed with this? Where should I be looking?
Thanks.
I'd start by looking at template Haskell for this. The various reify functions let you extract information from the compiler environment. I don't have a proof of concept around for this, but it looks like it should be doable.
For the task I'm working on, the signal system of the Elm programming language seems to be an appropriate solution.
But my pure computational functions are implemented in Haskell. Is there a Haskell library that would allow me to construct a signal graph (with my pure functions in the nodes) so that it works like in Elm?
My background
I need to observe intermediate results of a huge computation, on demand, i.e., I don't want to actually format and output each intermediate result, but if it is requested, then I should respond with the most fresh intermediate result (received from the computation signal).
Actually, there are several parallel computations, and some of them use the result of others, so I want several independent output signals for observing them. So I believe I could write an Elm program modeling the system to observe the intermediate results as they are available. (Perhaps, I'm wrong, I should try to write a prototype at least in Elm probably, but I'm also thinking about integrating with my main Haskell code already.)
Helm, which I am currently maintainer of, might be what you are looking for. It does combine the signalling with an SDL window that will always appear. You might be able to hack the render function and still use Helm's Signal without SDL or you could just take inspiration from Helm and write a similar Signal type using Elerea (which Helm uses in the background).
An even better idea might be to modify Helm to allow for use cases where main might not have anything to display and send us a pull-request.
From a comment by
Tekmo
to the announcement of "Elm 0.15: Tasks, Mailboxes, and import
syntax":
The Haskell version of mailboxes is pipes-concurrency. The analog
of Elm's Address is an Output and the analog of a Signal is an
Input.
(BTW, this seems to be very close to what I was looking for. Initially, in
previous versions of Elm, the abstractions I actually wanted seem to
have been missing, but tasks and mailboxes might fit my needs
quite well. So, and now I know--thanks to the comment by Tekmo--that
a similar Haskell library is pipes-concurrency.)
PureScript looks very similar to Haskell. It seems to me that large parts, mostly the pure parts, of a PureScript program should be compilable as well by a Haskell compiler. Is that right?
This leads to a related questions: Would it be possible to share code between a Haskell server backend and a PureScript frontend, e.g. data structures, form validations?
This is still a work in progress, but here are some of the differences for a start. We should have a new site soon that will make this kind of information easier to find!
Sharing code is good thing to have and it eliminate lot of redundancy, however, you might share type between ps and haskell using purescript bridge.
However, to gain more control of sharing code, I think you should use the same language on both the front end and backend and I think this is one of the main reason reflex was created.
If you are more into reactjs and flux architecture you can use react-flux and I heard that some people using it in production with good sucess.
I'm looking for a way to run an arbitrary Haskell code safely (or refuse to run unsafe code).
Must have:
module/function whitelist
timeout on execution
memory usage restriction
Capabilities I would like to see:
ability to kill thread
compiling the modules to native code
caching of compiled code
running several interpreters concurrently
complex datatype for compiler errors (insted of simple message in String)
With that sort of functionality it would be possible to implement a browser plugin capable of running arbitrary Haskell code, which is the idea I have in mind.
EDIT: I've got two answers, both great. Thanks! The sad part is that there doesn't seem to be ready-to-go library, just a similar program. It's a useful resource though. Anyway I think I'll wait for 7.2.1 to be released and try to use SafeHaskell in my own program.
We've been doing this for about 8 years now in lambdabot, which supports:
a controlled namespace
OS-enforced timeouts
native code modules
caching
concurrent interactive top-levels
custom error message returns.
This series of rules is documented, see:
Safely running untrusted Haskell code
mueval, an alternative implementation based on ghc-api
The approach to safety taken in lambdabot inspired the Safe Haskell language extension work.
For approaches to dynamic extension of compiled Haskell applications, in Haskell, see the two papers:
Dynamic Extension of Typed Functional Languages, and
Dynamic applications from the ground up.
GHC 7.2.1 will likely have a new facility called SafeHaskell which covers some of what you want. SafeHaskell ensures type-safety (so things like unsafePerformIO are outlawed), and establishes a trust mechanism, so that a library with a safe API but implemented using unsafe features can be trusted. It is designed exactly for running untrusted code.
For the other practical aspects (timeouts and so on), lambdabot as Don says would be a great place to look.
I'm a reasonably competent programmer who knows haskell, but who hasn't used it in any major projects. I know enough about c and systems and network programming that I believe I can pick apart tsocks from the source code.
I don't have any experience with the low-level systems interfaces haskell provides. I'm looking for any advice people can offer me on the topic, including, "Don't do it; you'll hate yourself for it," provided there is an explanation.
I really wouldn't do this, except as an experiment. I'm a Haskell guy, but not a deep systems guy, so there's a caveat there. But nonetheless, I see the following on the tsocks page:
tsocks is based on the 'shared library
interceptor' concept. Through use of
the LD_PRELOAD environment variable or
the /etc/ld.so.preload file tsocks is
automatically loaded into the process
space of every executed program. From
there it overrides the normal
connect() function by providing its
own. Thus when an application calls
connect() to establish a TCP
connection it instead passes control
to tsocks. tsocks determines if the
connection needs to be made via a
SOCKS server (by checking
/etc/tsocks.conf) and negotiates the
connection if so (through use of the
real connect() function )
It is possible to call Haskell from C, and vice-versa. And its relatively easy, in fact. For shared libraries, see this: http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/using-shared-libs.html.
But when you invoke Haskell from C, you need to A) link in the runtime and B) invoke the runtime.
So that works when the C knows that its calling Haskell. But its relatively trickier when the C doesn't know that it's calling Haskell, and so you'd need to wrap the Haskell shared library with a C library that invoked and managed the runtime transparently to the program that is preloading the haskell-tsocks library to intercept its normal connect functions.
So I'm sure this can be done -- but it sounds rather painful and complicated, and somewhat expensive in terms of having to link the whole ghc runtime in for this one feature. And frankly, I imagine the code you'd be writing (I haven't inspected the tsocks code itself yet) would largely be FFI calls anyway.
So a Haskell implementation of some element of socks -- a proxy, a client, etc. sounds interesting and potentially useful. But the exact preload magic that tsocks does sounds like a perhaps poor fit.
Bear in mind that there are Haskell hackers that are much better at this stuff than me, more knowledgeable, and more experienced. So they might say otherwise.
(Posting as a separate answer, since this is advice unrelated to the FFI)
You probably know this stuff, but in case its useful for anyone...
Read up on the Network.Socket module
Search the Haskell Wiki for pages that might help you (like Applications and libraries/Network)
Check out System Programming in Haskell and other chapters from RWH
Ignore the people that say "Haskell is terrible for I/O" - protip: you can just scare them away by saying fancy words like "endofunctor"
This may not be exactly the answer you were looking for, but instead of re-writing it in Haskell, you could just use the Foreign Function Interface to wrap the already-existing C implementation in Haskell types.
Note, one of the few major changes in Haskell 2010 was to officially include the FFI as a language feature. Link: Haskell 2010 FFI