I'm trying to build a web app halfway between tryhaskell.org and openjscad.org. Where a user can enter Haskell code for a module that defines a solid object, evaluated server side, with the resulting object displayed in the browser.
I already have an implementation of the CSG functions required.
I'd like to be able to use mueval to safely run untrusted Haskell, much like tryhaskell.org.
I can't see how to use mueval to safely run Haskell code, including function definitions, as opposed to just evaluating Haskell statements.
I'm aware of the --loadfile argument to mueval, but this doesn't give the same security guarantees as mueval provides when evaluating expressions.
Is it possible to use mueval (or something like it) to safely evaluate untrusted Haskell modules?
I'm currently hacking my way through trying to make quasiquotes for writing Rust code inline in Haskell. I think I have the code generation work done (including things like marshaling Haskell types to and from generated Rust ones). I now have the problem of figuring out how to do all the compilation and linking from within Template Haskell. The pipeline is as follows:
The quasiquote gets parsed
Source code is generated for
a corresponding Rust function
Haskell FFI imports
the Haskell call to the imported function
The Rust code gets compiled into a static library (like rustc --crate-type=staticlib qq_function.rs -o qq_function.a)
The Haskell code gets compiled and linked against qq_function.a (and a handful of other libraries like m, c, etc.)
My issue is getting steps 3 and 4 to happen entirely within TemplateHaskell. Here is as far as I've gotten:
runIO can write out the Rust source files that I've generated
addDependentFile informs GHC that the generated Rust file is a dependency
addForeignFile regrettably does not work for automatically managing the compilation since Rust is not a supported language (this is the approach inline-c takes since C is a supported language)
runIO could be used to generate the static Rust library (and delete the Rust source file afterwards) by calling out to rustc.
What is still very much not clear to me is
how I can use Template Haskell to add libraries against which to link and
how I can use Template Haskell to clean up these generated libraries afterwards?
EDIT
I've filed a GHC feature request related to this.
Computers can only understand machine language. Then how come interepreters execute a program directly without translating it into machine language? For example:
<?php
echo "Hello, World!" ;
It's a simple Hello World program written in PHP. How does it execute in machine while the machine has no idea what echo is? How does it output what's expected, in this case, the string Hello, World!?
Many interpreters, including the official PHP interpreter, actually translate the code to a byte code format before executing it for performance (and I suppose flexibility) reasons, but at its simplest, an interpreter simply goes through the code and performs the corresponding action for each statement. An extremely simple interpreter for a PHP-like language might look like this for example:
def execute_program(prog)
for statement in prog.toplevel_statements:
execute_statement(statement)
def execute_statement(statement):
if statement is an echo statement:
print( evaluate_expression(statement.argument) )
else if statement is a for loop:
execute_statement(statement.init)
while evaluate_expression(statement.condition).is_truthy():
for inner_statement in statement.body:
execute_statement(inner_statement)
execute_statement(statement.increment)
else if ...
Note that a big if-else-if statement is not actually the cleanest way to go through an AST and a real interpreter would also need to keep track of scopes and a call stack to implement function calls and returns.
But at its most basic, this is what it boils down to: "If we see this kind of statement, perform this kind of action etc.".
Except for being much more complex, it isn't really any different from writing a program that responds to user commands where the user could for example type "rectangle" and then you draw a rectangle. Here the CPU also doesn't understand what "rectangle" means, but your code contains something like if user_input == rectangle: [code to draw a rectangle] and that's all you need.
Strictly speaking, the interpreter is being executed and the code that the interpreter is interpreting just determines what actions the interpreter takes. (If it was just compiled to machine code, what would you need the interpreter for?).
For example, I built an automation framework awhile back where we captured reflection metadata on what was occurring at runtime during QA tests. We serialized that metadata to JSON. The JSON was never compiled to anything - it just told the automation engine what methods to call and what parameters to pass. No machine code involved. It wouldn't be exactly correct to say that we were "executing" the JSON - we were executing the automation engine, which was then following the "directions" found in the JSON, but it was certainly interpreting the JSON.
I have a TH-heavy file which takes around 30 seconds to compile. What are some techniques I can use to help debug the performance of my Template Haskell?
If I understand compile flow of TH correctly, the ordinary haskell functions are being executed while splicing at compile time. But you can run then at the runtime on your own, of course.
For example you have something like $(foo x y ...) in your TH-heavy file. Create another file and call 'foo x y' there but don't splice the result. Then you'll be able to profile 'foo' as usual. If the bottleneck is at the AST generation stage you'll locate it. Don't forget to consider lazyness.
As of GHC 8, this can be done with -fexternal-interpreter.
Compile the library defining the TH function with profiling enabled, then compile the code* which uses the TH function in a splice with GHC options -fexternal-interpreter -opti+RTS -opti-p. This should produce a file called ghc-iserv-prof.prof.
This approach has the advantage that you can use the full functionality of the Q monad.
* A benchmark suite in the same cabal project as the TH library (but in a different hs-source-dir) also works. It might even work with a TH function defined and used in the same library, but I think you'll be profiling interpreted code then.
I wondered if there is a programming language which compiles to machine code/binary (not bytecode then executed by a VM, that's something completely different when considering typing) that features dynamic and/or weak typing, e.g:
Think of a compiled language where:
Variables don't need to be declared
Variables can be created during runtime
Functions can return values of different types
Questions:
Is there such a programming language?
(Why) not?
I think that a dynamically yet strong typed, compiled language would really sense, but is it possible?
I believe Lisp fits that description.
http://en.wikipedia.org/wiki/Common_Lisp
Yes, it is possible. See Julia. It is a dynamic language (you can write programs without types) but it never runs on a VM. It compiles the program to native code at runtime (JIT compilation).
Objective-C might have some of the properties you seek. Classes can be opened and altered in runtime, and you can send any kind of message to an object, whether it usually responds to it or not. In that way, you can implement duck typing, much like in Ruby. The type id, roughly equivalent to a void*, can be endowed with interfaces that specify a contract that the (otherwise unknown) type will adhere to.
C# 4.0 has many, if not all of these characteristics. If you really want native machine code, you can compile the bytecode down to machine code using a utility.
In particular, the use of the dynamic keyword allows objects and their members to be bound dynamically at runtime.
Check out Anders Hejlsberg's video, The Future of C#, for a primer:
http://channel9.msdn.com/pdc2008/TL16/
Objective-C has many of the features you mention: it compiles to machine code and is effectively dynamically typed with respect to object instances. The id type can store any class instance and Objective-C uses message passing instead of member function calls. Methods can be created/added at runtime. The Objective-C runtime can also synthesize class instance variables at runtime, but local variables still need to be declared (just as in C).
C# 4.0 has many of these features, except that it is compiled to IL (bytecode) and interpreted using a virtual machine (the CLR). This brings up an interesting point, however: if bytecode is just-in-time compiled to machine code, does that count? If so, it opens to the door to not only any of the .Net languages, but Python (see PyPy or Unladed Swallow or IronPython) and Ruby (see MacRuby or IronRuby) and many other dynamically typed languages, not mention many LISP variants.
In a similar vein to Lisp, there is Factor, a concatenative* language with no variables by default, dynamic typing, and a flexible object system. Factor code can be run in the interactive interpreter, or compiled to a native executable using its deploy function.
* point-free functional stack-based
VB 6 has most of that
I don't know of any language that has exactly those capabilities. I can think of two that have a significant subset, though:
D has type inference, garbage collection, and powerful metaprogramming facilities, yet compiles to efficient machine code. It does not have dynamic typing, however.
C# can be compiled directly to machine code via the mono project. C# has a similar feature set to D, but again without dynamic typing.
Python to C probably needs these criteria.
Write in Python.
Compile Python to Executable. See Process to convert simple Python script into Windows executable. Also see Writing code translator from Python to C?
Elixir does this. The flexibility of dynamic variable typing helps with doing hot-code updates (for which Erlang was designed). Files are compiled to run on the BEAM, the Erlang/Elixir VM.
C/C++ both indirectly support dynamic typing using void*. C++ example:
#include <string>
int main() {
void* x = malloc(sizeof(int))
*(int*)x = 5;
x = malloc(sizeof(std::string));
*(std::string*x) = std::string("Hello world");
free(x);
return 0;
}
In C++17, std::any can be used as well:
#include <string>
#include <any>
int main() {
std::any x = 5;
x = std::string("Hello world");
return 0;
}
Of course, duck typing is rarely used or needed in C/C++, and both of these options have issues (void* is unsafe, std::any is a huge performance bottleneck).
Another example of what you may be looking for is the V8 engine for JavaScript. It is a JIT compiler, meaning the source code is compiled to bytecode and then machine code at runtime, although this is hidden from the user.