>Of course you can. In fact, it's the best way to make interactive languages on .Net
I should have said "you shouldn't use reflection.emit for a new language."
I thought you were talking about passing some arbitrary language code to reflection.emit and getting CIL. Instead you want to interpret some new language with C# and pass that output to Reflection.Emit.
Here is any MSDN article about doing that.
http://msdn.microsoft.com/en-us/magazine/cc136756.aspx
That method has a lot of pitfalls and the conclusion at the end of the article is, use the DLR.
I have looked extensivley at both methods for a project I did. Initially I though of just using VB.Net or C# from some scripting. But after exploring the DLR and talking to some of the devs (it is open source) I went the DRL route and glad I did. The environment I setup will be able to run dozens of lanugages as they are released without any modification, and the performance was acceptable.
>You're splitting hairs, but you're still wrong. Interactive compilers do not write the mnemonics to a text file. They generate the assembly in-memory and run it directly.
By default, .Net compilers compiler to CIL (write the mnemonics to a text file) then assembler that.
But what I was really talking about is a person would write mnemonics. A person normally would not write an entire program in opcodes.
>I do howerver think your notion of first-classness is misplaced.
Jython is not Python running on the JVM. It's Python syntax executing as Java would. It is not first class because it has restrictions. An Object (as in base object type too) in Jython is not the same as a Java Oject. It's all wrapped an marshalled and imposes restrictions.
Iron Python has no such restrictions.
>As a result, it tends to not be as well-optimized, but it does make implementing many semantics easier.
Java's strange half assed backwards compatibility means it is not open to significant optimizations of new features it implements. Java runs about as well now as it ever will.
>That exactly how it works. You load that .txt into memory, and point %eip at it, it will run.
No. The binary that makes up the text file is different than the binary that makes up the assembelled program. An x86 CPU can't assemble programs on its own.
>Your point is that IL bytecodes are significantly better than JVM bytecodes because of STandard low level code modification?
IL bytecode does not exist. There is the CIL object oriented assembly language for the CLI, and there is bytecode which represents the assembled instructions of CIL for CLI. We have gone over this a dozen times.
As Sun stated, there is no standard way to represent bytecode in a low level language. One person might have use mov, the other might use mvr for the same fucking thing. Anyone can use whatever they want. So others would need to learn each mnemonic for each implementation for the same fucking thing. That prospect is unreasonable at best.
>And as many people have pointed out, there are many languages on the JVM as well.
And as I have pointed out, implementing the syntax does not mean the language works like its native implementation. It can only approximate in on the JVM.