Hacker News Reader

Comment by ssp | Hacker News Reader

C is more a description of a Harvard machine than a von Neumann machine. In fact, a useful new language feature would be dynamic generation of machine code.

View on HN

Of course this isn't a feature of the language -- but most implementations (e.g. gcc) technically allow this, if you really, really know what you're doing. For example:

http://www.cesarbs.org/blog/2010/07/19/run-time-machine-code...

Writing code that writes code, where that written code is executable at machine speeds rather than interpreted, is a qualitative difference over a simple "eval" implementation; and it can most definitely be a feature of the language.

A language which supports it as a feature may do things like partial evaluation of closures, inlining of runtime-constructed code, transforming e.g. the typical block-passing idiom of a Ruby into specific optimized cases. Being able to rely on such transformations in turn lets you build more abstract (i.e. more highly parameterized) libraries because you know you won't have to pay the same degree of abstraction tax.

Yes, you can generate machine code yourself, but then you have to write machine code ...

I'm suggesting a JIT compiler as a built-in language feature so that you could write code in a high-level language and have machine code generated that was specialized based on the program's dynamic state.

It could be done as a library, but it would benefit from language integration so that you wouldn't have to write the code as strings or ASTs.

Language integration would be nice, however dynamic code generation from a library has been about for some time now:

"With libtcc, you can use TCC as a backend for dynamic code generation." from http://bellard.org/tcc/

Lisp provides exactly that: functions are lists (primary data structure of the language) of expressions (in VM's instructions) and you have direct access to VM's memory cells (conses, [1]). You can generate and change functions at runtime. For example, inject tracing code. Actually, at least in some implementations, all functions are created dynamically, except for a few core functions (implemented with C, d'oh).

And how `new' it is? 1958. Oh dear.

Re: ``C is more Harvard than von Neumann architecture''. Hardly; C is architecture agnostic. You can compile it for a Harvard PIC as well as for von Neumann CPU.

It may seem functions are execute-only, but on common CPUs you can treat them as data as well: read and modify (modulo memory protection). And the other way around too -- you can load a bunch of bytes from a DLL, resolve symbols to obtain pointers and use the pointers to execute the loaded bytes as functions.

[1] http://en.wikipedia.org/wiki/Cons

Only in early Lisps (and the broken newLisp) are functions lists.

The syntax for functions is lists. But at runtime functions are their own type.

Pardon? [1]

Are you sure? [2]

How about no? [3]

Perhaps you prefer Vim over Emacs? [4]

---

[1] http://en.wikipedia.org/wiki/Picolisp my favorite

[2] http://en.wikipedia.org/wiki/Scheme_(programming_language) probably the best known

[3] http://en.wikipedia.org/wiki/Arc_(programming_language) this bloody website runs on it

[4] http://en.wikipedia.org/wiki/Emacs_Lisp the good, the bad and the ugly, all in one package

In Scheme try and compare

   (car (list 1 2 3 4))

with

   (car (lambda (x) x))

But I guess we are talking about different levels of abstraction?

Not that this has too much to do with what you two were talking about, but (car '(lambda (x) x)) will return lambda in Scheme.

You are right.

Actually I was almost going to add (car '(lambda (x) x)) to my post in the first place; in line with `The syntax for functions is lists.'

Indeed, you are right about Scheme (and Arc). Thanks for the correction.

Sure, no problem. I guess Emacs Lisp falls under the old-and-broken category. And Picolisp eschews functions as a data-type by choice. Do you know whether Picolisp offers lexical scoping?

As the other response says. The FAQ provides some rationale & makes it clear you can, actually, build robust software with picolisp's model of scoping. My understanding is, ``dynamic scoping is faster for an interpreter'' and ``funarg is easy to avoid and closures are possible''.

See the three following points:

http://www.software-lab.de/doc/faq.html#dynamic

http://www.software-lab.de/doc/faq.html#problems

http://www.software-lab.de/doc/faq.html#closures

It offers something similar-but-not-quite called transient symbols: http://www.software-lab.de/doc/faq.html#problems

Alternative phrases for similar-but-not-quite: insidious, error-prone.

http://pdos.csail.mit.edu/tickc/

It's C++ and of course dependent on Unix/Windows memory mapping APIs, but you might like asmjit: http://code.google.com/p/asmjit/

Reply on news.ycombinator.com