[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scriptometer: measuring the ease of SOP (Script Oriented Programming)of programming languages
Daniel Weinreb wrote:
>> 1. is the JVM (or .NET) a nice bytecode to build scripting languages
>> on top of it?
>> 1. I don't know much about this. All I can say is that JVM is
>> dynamically typed and reflexive and this helps. A pb may be
> At LL1, the Perl folks explained that they were writing a whole new VM
> the JVM was inadequate to do what they needed. I suggested that
> explaining the
> details of this would make a great paper. It would sure be nice if
> somebody, within
> the Perl team or not, would understand what's going on and write a paper
> about it.
> Perhaps someone could find a student for whom this would be a suitable
There is a paper on porting Python to the .NET Framework that has a
relevant section (could apply as well to the JVM as to .NET):
Possible .NET or Python enhancements
This section describes a few changes that could happen to Python and/or
.NET that we could take advantage of.
As can be seen from the previous section, there is plenty of work still
to be done before we take full advantage of .NET given the current state
of both .NET and Python. Therefore, we limit this section to be brief
discussion of the possibilities, and save further analysis for when the
existing implementation could be considered of usable quality.
There has been discussion in the Python community about adding optional
type declarations to the next major version of Python. Although
consensus has not been reached, the proposals being discussed would
support all of our type declaration requirements – declaring the
signature when implementing a method, and selecting which signature you
wish to call.
However, once we have syntactic support, the compiler will obviously
need to be enhanced to take advantage of the declarations. Indeed, this
is probably the biggest issue preventing Python from moving forward with
concrete syntax proposals – it is still not clear anyone has the time or
inclination to enhance the CPython runtime to take full advantage, so
therefore the syntax enhancements would be pointless. If a commitment
from the JPython or Python for .NET projects was made to support these
enhancements, it may help accelerate the acceptance of these proposals
into the Python language specification.
Dynamic language support.
Due to Python’s dynamic nature, there are some Python features that are
difficult to map into .NET semantics. A simple example is the ability
for a Python object to add attributes at runtime – although no
declaration or other reference to the attribute can be seen by source
code analysis, reference to the attribute will succeed at runtime.
Python provides many other ways to change object behaviour at runtime
that are not captured by .NET.
To support this capability, the compiler will often emit special symbols
or code specific to Python. At runtime, if these features are found
they are used, and thus Python can take advantage of these features.
This allows Python code compiled in a separate compilation unit (that
is, it exists in a separate assembly) to still provide these dynamic
Python semantics when the caller is Python.
This dynamic capability is analogous to IDispatch support in COM – the
ability for a language to dynamically determine or expose an object
model at runtime. .NET is focussed much more towards compile time
determination of these attributes, in a clear drive for speed. However,
the very nature of Python and scripting languages in general is that
their users have made a conscious decision to trade execution speed for
these runtime features – although possibly not as much execution speed
as Python for .NET is currently costing them.
It is clear such dynamic features may preclude certain other .NET
features - for example, the performance penalty associated with allowing
dynamically obtained methods to be used as virtual methods may mean they
are not supported as virtual. However, there is still enough utility in
the feature overlap that would make this a useful, but optional .NET
It should also be noted that there are many languages with dynamic
features comparable to Python. However, with Python and every other
such language needing to invent its own dynamic solution, these
languages are not able to share such features, even when it would make
sense to be able to do so. Formalization of these features in .NET
would allow multiple dynamic languages to interoperate in a natural manner.