in reply to ActiveState Perl for .NET

ActiveState's Perl for .NET is an unmanaged component, if that makes any difference to you. It doesn't so much turn perl in to .NET code as embed a perl interpreter in your .NET app and just pass off the perl code to it.

Actually translating perl to .NET is... an interesting task. (Having looked at it for Parrot) It's certainly possible, but it'll either be slow or require crippling some of the interesting parts of perl.

Replies are listed 'Best First'.
Re: Re: ActiveState Perl for .NET
by demerphq (Chancellor) on Apr 19, 2002 at 15:20 UTC
    Whats an unmanaged component?

    Yves / DeMerphq
    ---
    Writing a good benchmark isnt as easy as it might look.

[reply]
      Basically something that's not .NET code. There are security implications (Unmanaged code can be insecure, as it bypasses most of .NET's security features) and potential stability issues.

      Think of it as XS for .NET--while you can do anything you want and interface to some external library or other, there's nothing to stop the code from stomping on the world. It also means you'll need the perl component on any machine executing your perl code in the .NET environment, though I think .NET's packaging scheme takes care of fetching that as need be. (I'm not 100% sure of that, thoug)

[reply]
        My understanding (based on the little technical info provided during the .NET Launch party in Las Vegas last month) is that unmanaged code allows you direct contact with the hardware as opposed to the CLR handling that low level happiness. The implication being that you are responsible for your own memory mangagment, garbage collection, etc. (primarily an issue for C and C++ folks!)

        Does this sound like it lines up with your understanding, or am I totally off-base ;).

        -Brett

[reply]

In Section Seekers of Perl Wisdom