So Dan was right on both counts.
('''Either Dave thinks it just
can't be done, or he really, /really/ wants this compiler.''')
I'm sure it can be done. I just don't think *I* can do it. =) At least, I
have very little experience in writing compilers or anything like that...
What version of the SWF format are you stuck writing to? It
appears that even SWF 5 supports Javascript-style "dictionaries"
by using attributes on an object. For example, "ActionEnumerate"
will let you iterate over all properties on an object ala the
Python "for k in dict".
Flash MX, which is SWF 6 I think. It is true that you can (ab)use objects as
dictionaries, but this has several unforunate consequences:
- Keys must be strings. All objects will be toString()-ed.
- Keys are case-insensitive (until SWF 7, I suppose).
- Adding methods to the dictionary class.
(to support .keys(), .values(), etc.) requires modification of the Object
prototype, and thus the use of undocumented features (ASSetPropFlags) to
hide these methods from "for ... in ..." loops.
- There is no exception on a bad key, since there are no exceptions
(pre MX 2004, anyway), so the only way to even get an error report is
to use another undocumented feature, the "__resolve" method.
- Implementing dictionaries as nested arrays, to get around the case
insensitivity issue and string requirement for keys, has the most
awful performance I've ever seen in any language.
As for exceptions, they were added in SWF 7, so I'm guessing you're
stuck somewhere prior to that. Your life must really suck. ;-)
Well, I'm getting by. But there are so many times when I think "Wow...
Python really got this right". You don't realize how many ways things can go
wrong when you're spoiled by the good design decisions behind a language
like Python. I've had this feeling many times over.
Gosh you set a high target. Much as I like the taste of pie
(Mmmmm... piiiiie), and that cold clammy feeling as it drips down
inside my shirt, I don't think I'll be accepting the challenge any
time soon. Not, at least, until I learn a lot more about compilers
than I currently know (hint, it involves the word "sweet" and "all").
See, I shouldn't have blown my cover. I could've at least gotten a "print"
statement out of you before I opened my big mouth.
One thing that would help would be a little direction from
someone in the know as to how Jython handles things that are
simply not available in Java bytecode. For example, as far
as I know the main operators for basic primitive types in Java are
implemented with different bytecode instructions, while in
CPython things like "add" are implemented as a single bytecode
which happens to special case integers for performance, but
falls back to a dynamic lookup if the types being added are
not integers.
Well, in ActionScript, and I'm guessing this applies even at the bytecode
level, things are very weakly typed. Numbers are transparently coerced to
Strings and back, all the time. There's a single "add" instruction that is
used for Numbers and Strings, performing addition, concatenation, and
coercion as necessary. At least, so it seems looking at the FLASM dump of my
program.
That looks to me like a bit of a conundrum. To turn the Python
code into the appropriate Java bytecodes, wouldn't you have to
know the types of the data during compilation (as in static
data types)? But Python doesn't have that (yet), so how is
it done? Are all "adds" sent to some library routine which
is made available to all applications, and that routine then
handles the Python-style dynamic add operation?
I like key lime, but not banana cream. Apple and rhubarb are good, too.
In some ways, I think the SWF bytecode is even closer to Python
than Java's bytecode is, but I'm pretty sure that I couldn't
begin to imagine how one would target either of them...
I'm sure it is, since it was designed with a dynamically typed language in
mind. They're similar though; they're both stack-based, and they both
support some notion of objects at the bytecode level.
Let me know when it's ready. Thanks.
Dave