Cameron Zemek <[EMAIL PROTECTED]> wrote:
> The FAQ mentions that the JVM and CLR (.Net VM) are not suited to
> dynamic languages. I was wondering why this is the case.
Dynamic languages have a few features in common:
- Very weak typing with lots of automatic conversion.
- Oddball control flow constructs (closures, co-routines,
continuations, and a few things that don't start with C).
- An "eval" or similar function.
The first feature isn't well-supported in the CLR or JVM, and would
probably require quite a bit of extra code to handle. The second is
at best extremely difficult to implement. The third...well,
ActiveState tried to write a Perl-to-.NET compiler; they almost
succeeded, *except* that runtime code evaluation wouldn't work.
(IIRC, anyway.)
Some languages go even farther than those basic characteristics; Perl
5, for example, has four hooks to run code at odd times (as soon as
it's parsed, once compilation is complete, immediately after execution
starts, and right before the program closes). Perl and Python at
least have object formats that don't quite fit native CLR or JVM
objects.
In general, the CLR and JVM just aren't a good fit for these languages.
> Also could the Parrot VM be used effectively with strong typing
> languages.
I expect so. Parrot's variables are represented by a structure called
a PMC, which is essentially an object with a fixed table of methods.
(It's written in preprocessed C, though, so there isn't really an
"object" involved--it's just a struct.) Those methods can do
anything, including whatever validation you want to add to them.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
