[Swift-devel] status of conversion of bug 30: making the xml intermediate form more XML-like

[Ben Clifford]

At present, the XML intermediate form (between the user written 
SwiftScript form and the karajan code) is partly XML and partly other 
languages.

This makes parsing of the XML language hard and thus the language somewhat 
buggy.

In practice, this has resulted in wasted time and frustration for various 
people in this group trying to write applications.

So I'm working on converting the XML intermediate language to be more 
XML-like without the various embedded non-XML / quasi-XML languages that 
are there.

I have a basic implementation that is not ready for real use but seems to 
behave mostly ok.

A couple of caveats:

 i) different number types are not supported - there is a bunch of 
implicit type conversion between ints and floats that happens inside the 
present runtime. As part of tightening up the type checking, this messed 
up a bunch of numerical stuff so I temporarily have made my development 
code only accept integers - no floats (I don't know of anyone who uses 
non-integers in programs, though).

I need to think some more about implicit type conversion and how operator 
overloading should work - at the moment in production a lot of semantics 
are inherited from karajan that are maybe but not necessarily what are 
right.

 ii) The present production implementation has a dual type model - 
sometimes data flows around as java objects of types such as Integer or 
String; sometimes it flows around as DSHandle objects which contain those 
values. The need to convert between those at many points causes trouble. 

My development code keeps values in DSHandle objects as much as possible.

This is some additional runtime overhead (because the expression 1 + 2 now 
creates three intermediate DSHandle objects, rather than evaluating the 
expression as the Karajan level and wrapping at the end).

However, in practice expressions are not used very much and so this 
overhead is hopefully not excessively onerous. If it is, there is scope 
for optimistion to happen at the xml->kml layer (as I'm doing with path 
handling).

--