[Haskell-cafe] ANNOUNCE: tls,
native TLS/SSL protocol implementation
fw at deneb.enyo.de
Sat Oct 9 14:17:24 EDT 2010
* Donn Cave:
> Quoth Florian Weimer <fw at deneb.enyo.de>,
>>> wikipedia: "Managed code is a differentiation coined by Microsoft to
>>> identify computer program code that requires and will only execute
>>> under the "management" of a Common Language Runtime virtual machine
>>> (resulting in Bytecode)."
>> I like this term, I apply it by extension to any system which enforces
>> memory safety (as long as you stick to non-internals, such as array
>> indexing, even Java has got (in practical terms) fairly portable
>> PEEK/POKE operations).
> ... enforces memory safety? Can't that be done in code compiled straight
> to CPU instructions without even calling a run-time, let alone being
> managed by one?
It is quite possible to have memory-unsafe interpreted languages. I
wouldn't necessary call them "managed". For example, a simple
interpreted Forth might have explicit words for heap allocation and
deallocation. This isn't a interpreted/compiled distinction (and the
line between the two is increasingly blurred because there are
high-performance compilers these days for languages which are
traditionally considered interpreted).
You need restrictions on memory deallocation (which must follow a
stack or region descipline), and thus indirectly on allocation. I
don't think region inference has caught on, which suggests that there
are inherent limitations when trying to apply it to application code.
> I'm not sure what you mean, but in this case, the term has surely
> been extended too far - it doesn't seem to be managed code in the
> sense quoted above, nor does it seem to fit with common
> non-technical usage of "managed".
Not really---many C programmers associate memory safety with
micromanagement by the language environment.
>>> In other words, a new way to say `interpreted',
>> This term doesn't really apply that well to the CLR because its
>> bytecode really can't be interpreted efficiently. (The bytecodes lack
>> type information.)
> To me, the CLR takes bytecode, maps it in some way to CPU machine code
> and executes the latter. I would call that "interpreted", but you
> wouldn't? Or am I wrong about what's happening? I know Wikipedia
> isn't necessarily the ultimate authority of computer science, but
> "Many interpreted languages are first compiled to some form of virtual
> machine code, which is then either interpreted or compiled at runtime
> to native code." (... going on to cite Java and .NET Framework among
> others), so I'm not the only one who finds it expedient to use that
> word "interpreted" in this context.
I think the word is increasingply meaningless. Current x86 CPUs
(excluding the low-power variants) turn transform the instruction
stream before execution, too. Your VM hypervisor might emulate the
effect of certain instruction sequences which cannot be virtualized
solely in hardware. C language environments contain run-time code
generation to tune for the specific CPU on which they are running.
And historically, even C was compiled to bytecode, so that large
programs could fit into available RAM. And so on.
> At this point, I still don't know for sure if you think a
> GHC-compiled Haskell program is managed, or unmanaged, but I think
Yupp, it's managed (at least according to my own use of the word).
Haskell tries quite hard to protect its own abstractions (which is
essentially another view on memory safety).
> And in my confused present state I would say it's unmanaged.
Johan Tibell speaks of the "GHC I/O manager", so I think I'm in good
More information about the Haskell-Cafe