The forced execution of souce code

How's called the ability of a language to interpret new code at runtime (the keyword/function that does this is typically called eval)?

For example Perl, Python, JavaScript and most shell languages have this. C and C++ haven't it.

Does Haskell have it? What about C#?

Note that shit like manually invoking the compiler doesn't count.

IHBT

>>2
Y'AHBT

Please learn the basics of computer languages design and interpretation.

U MENA HASKAL??

Do you mean an interpreter?
Also don't generalise, interpreters are different for every language.

For isntance Matlab uses a interpreter and so does Java.
In really different ways.

=Please learn the basics of computer languages structure and interpretation.

>>1
To be specific, execution of a Perl file is its own interpretation, translating the source code into an intermediate code that can be executed.  To my knowledge, woefully lacking though it is, this is just called a dynamic programming language.  It performs functions at runtime that another language - C++, Java, etc. - can perform only after being compiled.

>>10
How? The only people who think there's any significant difference between compiled and interpreted languages are C++ programmers, and they're wrong.

>>1
EVAL can be replaced by a call to COMPILE, which is what a lot of Lisp implementations which only have compilers do.

C and C++ haven't it.
They do, but it's implementation specific: you can call your compiler and then dynamically load the code at runtime. This won't take more than a few pages of code, unless you go all [b][b][u][i][o]ENTEPRISE[o][/i][/u][/b] about it. You can also make a slow C interpreter or use one already available, but I'm not sure there's much of a point in it.
What about C#?
C# does it the same way as you would do it in C, except it's portably supported. You can compile a new module and load it at runtime. I'm sure interpreting is also possible, but I haven't seen a C# interpreter, but I've seen plenty of cases of compiling and loading new code at runtime.

Note that shit like manually invoking the compiler doesn't count.
Now you tell me... That's how most smart languages do it, especially when implementing an interpreter is more work (doesn't apply to Lisp, where metacircular interpreters can be done in very little space), and the resulting interpreter is much slower than compiled code (the only exception to this is when compiling is slower for small pieces of code, which would be faster to interpret).

>>12
This won't take more than a few pages of code
popen >> fputs >> pclose >> dlopen >> dlsym

>>13
U MENA popen >>= fputs >>= pclose >>= dlopen >>= dlsym??

>>12

>>12
C# does it the same way as you would do it in C, except it's portably supported. You can compile a new module and load it at runtime.
There's also Expression<T> and DynamicMethod

Let me get this straight, you're asking if a compiled language can execute uncompiled code?

>>17
except perl is compiled

It's not just about executing "new" code, it's obvious you can do that in almost any language (however IMO it's an important distinction whether the language supports it natively or whether you have to manually supply an entire compiler implementation to do it).

What's interesting is
char buffa[9999];
i = 5;
gets(buffa);
eval(buffa);
printf("%d\n", i);
and then supporting an input like i += 1;

Obviously you're very fucked in C with normal compiled code, as the code itself has no notion of variable names, just to name the least of the problems.

So yeah, maybe you could call one type "dynamic" and the other "static", but I'm not sure this distinction and nomenclature are 100% right.

>>19
>Obviously you're very fucked in C with normal compiled code, as the code itself has no notion of variable names, just to name the least of the problems.
Not really... your eval function could just export i to the evalled program using plain old dynamic linking. Eval would prepend its input with "extern int i;" and everything would work great.

>>20
Only works for globals, can't do that for lexicals.

>>21
Why not? It isn't as automatic of course - you'd have to eval like eval(buffa, {{&i, "i", "int"}, {&j, "j", "long"}});, which is kind of ugly, but so is eval itself ;)

>>19-22
Erm, what's wrong with using the symbol table?

Also, gdb already can do eval for C, in a way. The trick is to extract that useful bit into a standalone library.

>>21
You can if you compile with debug symbols, then let eval extract the caller's local variables and inject their current stack addresses as private globals when linking the new code.

On this subject, is it at all possible to call a function with a non-hard-coded arity given a dlsym?

That is:

#include <stdio.h>
#include <dlfcn.h>
#include <stdarg.h>
typedef int fp(void*,...);
void apply(void *h, char *f, ...) {
    void *s = dlsym(h, f);
    va_list a;
    va_start(a, f);
    (*((fp*)s))(a);
    va_end(a);
}
int main(int argc, char **argv) {
    void *h = dlopen(NULL, RTLD_NOW);
    apply(h, "vprintf", "%d %d %d\n", 1, 2, 3);
}

This obviously doesn't work; but is there some trick to working around having to prototype every function separately?

>>25
I don't see why not, just obtain the function address, cast it to the right type and call it.

I have not done this on *nix, but I've done it on Win32/MS C using LoadLibrary*/GetProcAddress and the right casts, and the calling convention needs to be clearly specified when importing/exporting the function (be it stdcall(caller cleans up), cdecl(callee cleans up)) for it to work properly.

>>25
You can't convert a va_list back to real arguments, but I'm not sure why you want to create one in the first place.

#define apply(h, f, ...) (((int(*)())dlsym((h), (f)))(__VA_ARGS__))

int main(int argc, char **argv) {
    void *h = dlopen(NULL, RTLD_NOW);
    apply(h, "printf", "%d %d %d\n", 1, 2, 3);
}

>>27
EXPERT C99 PROGRAMMER

>>27
Except that's not right, because in C99 mode () args means (void).

>>29
Then don't use C99 mode.

>>30
Then your wrong.

>>31
what about his wrong?

^{Back to /b/, ``GNAA Faggot''}