Example of such a language is Java. It's runtime is highly dynamic. Class loaders allow you to create new classes, pre-process bytecode, and many other stuff.
You can even rerun portions of your code after you've modified it (rewind it), something that even Smalltalk never supported.
The JVM is a virtual machine targeted by many languages, some of which are dynamic, and Java isn't a "modern" static language from the standpoint of type theory and provability.
In Pharo Smalltalk, for example, you can pause running code in the debugger and modify it using syntax the language doesn't actually support, and then, in the same runtime, open a class browser and modify the compiler to support the new syntax before finally accepting your changes in the debugger and resuming execution. You can swap every reference to one object with references to another object using become:, effectively swapping the identities of two objects globally at runtime.
Perhaps all of this is possible in Haskell and the like, but it's still to be demonstrated.
> You can even rerun portions of your code after you've modified it (rewind it), something that even Smalltalk never supported.
Smalltalk and Lisp both support this.
Interesting, do you have a few pointers?
http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil...
http://malisper.me/2015/07/14/debugging-lisp-part-2-inspecti...
http://malisper.me/2015/07/22/debugging-lisp-part-3-redefini...
http://malisper.me/2015/08/05/debugging-lisp-part-4-restarts...
http://malisper.me/2015/08/19/debugging-lisp-part-5-miscella...
I was specifically talking about debuggers that let you rerun code after you've modified it without having to restart your application, something that Java debuggers have allowed for almost ten years now.
I continue to think that neither Lisp nor Smalltalk offer this functionality, can someone prove this wrong?
Java got this from Lisp and Smalltalk. The first and third links covers what you're talking about. For Pharo, which is graphical, just open the image, open the debugger on some code and modify it to your liking before clicking "Proceed," or alternately, pick an earlier stack frame and do the same.
Did you even read this paragraph:
> In Pharo Smalltalk, for example, you can pause running code in the debugger and modify it using syntax the language doesn't actually support, and then, in the same runtime, open a class browser and modify the compiler to support the new syntax before finally accepting your changes in the debugger and resuming execution. You can swap every reference to one object with references to another object using become:, effectively swapping the identities of two objects globally at runtime.
This is a formal way to do homoiconicity, and frankly much better than codewalkers and CPS-conversions and similar tricks.
I now think that everything you can do with macros in CL, you can do in Haskell too and it will be cleaner. Another good example are lens and traversals, they are generalizations of generic references such that CL can only envy.
Someone should really rewrite On Lisp and Paradigms of AI in Haskell.. (and also Design Patterns from GoF) I think it would prove this point.
This is an area where the state-of-the-art in static languages (Haskell, Idris, Agda) falls flat, and I suspect that's why (other than ignorance) we see so many comparisons from Haskell advocates between Haskell and the likes of Python, Ruby, or worse that try to paint dynamic languages as offering only brevity through the omission of type signatures as a major advantage over common static languages--an advantage for which Haskell can largely compensate--while completely ignoring the capabilities more sophisticated dynamic languages offer.