
Brett C. wrote:
- floating point: provide IEEE-794 (or some such) in a portable yet efficient way
You mean like how we have longs? So code up in C our own way of storing 794 independent of the CPU?
Not longs, but floats. And you would not attempt to store it independent of the CPU, but instead, you would make as much use of the CPU as possible, and only implement things in C that the CPU gets wrong. The portion of emulation would vary from CPU to CPU. As a starting point, you might look at the Java strictfpu mode (which got only added after the initial Java release). Java 1.0 was where Python is today: expose whatever the platform provides. In Java, they have the much stronger desire to provide bit-for-bit reproducability on all systems, so they added strictfpu as a trade-off of performance vs. write-once-run-anywhere.
- deterministic finalization: provide a way to get objects destroyed implicitly at certain points in control flow; a use case would be thread-safety/critical regions
I think you get what you mean by this, but I am not totally sure since I can't come up with a use beyond threads killing themselves properly when the whole program is shutting down.
Not at all. In Python, you currently do def bump_counter(self): self.mutex.acquire() try: self.counter = self.counter+1 more_actions() finally: self.mutex.release() In C++, you do void bump_counter(){ MutexAcquistion acquire(this); this->counter+=1; more_actions(); } I.e. you can acquire the mutex at the beginning (as a local object), and it gets destroyed automatically at the end of the function. So they have the "resource acquisition is construction, resource release is destruction" design pattern. This is very powerful and convenient, and works almost in CPython, but not in Python - as there is no uarantee when objects get destroyed.
Have no clue what this is since I don't know C#. Almost sounds like Michael's def func() [] proposal at the method level. Or just a lot of descriptors. =)
Yes, the func()[] proposal might do most of it. However, I'm uncertain whether it puts in place all pieces of the puzzle - one would actually have to try to use that stuff to see whether it really works sufficiently. You would have to set goals first (what is it supposed to do), and then investigate, whether these things can actually be done with it. As I said: static, class, synchronized, final methods might all be candidates; perhaps along with some of the .NET features, like security evidence check (caller must have permission to write files in order to call this method), webmethod (method is automagically exposed as a SOAP/XML-RPC method), etc. Regards, Martin