[Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation

[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?  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".

>> 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.

>> and `native' vs.  `interpreted' is a familiar distinction for more
>> computing environments than just Java.  But it isn't relevant here,
>> right?  Since neither the Haskell nor OpenSSL implementations are
>> both compiled to CPU instructions.
>
> Obviously, this depends on the implementation.  For Haskell and Java,
> implementations which are based on precompiled machine code exist.
> There are also implementations which rely on some form of
> interpretation exclusively.  That's why the managed/unmanaged
> distinction is more useful than the interpreted/compiled distinction.

I don't know, of course this is partly due just to my own ignorance,
but it seems to me that the awkward semantics around this distinction
make it somewhat prone to confusion.  Maybe the kind of thing that's
useful to your understanding of computational environments, but less
useful when discussing them with others?  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 managed?  And in my confused present state
I would say it's unmanaged.

	Donn Cave, donn at avvanta.com