Re: Scriptometer: measuring the ease of SOP (Script Oriented Programming)of programming languages

[Paul Prescod <address@hidden>]

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
>> performance.
>>
> At LL1, the Perl folks explained that they were writing a whole new VM 
> because
> 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 
> project.

There is a paper[1] on porting Python to the .NET Framework that has a 
relevant section (could apply as well to the JVM as to .NET):

http://starship.python.net/crew/mhammond/dotnet/index.html
====
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.

Type declarations

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

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.