this reminds me of a number of years ago... I had my own custom Scheme implementation, but this effort imploded due to a number of factors (in large part, the code had become unworkable and unmaintainable...). but, hell, this was my first non-trivial forray into interpreter and compiler technology (it had a compiler, as well as an interpreter, but this was several years before I started messing with JIT and SMC). (this was around 2001-2003).
but, after its demise, I tried at that point developing a new scripting language, derived primarily from PostScript... attempts to actually use it: "OMG this is horrible...". yes, it was terribly awkward to write in, and worse yet was trying to make sense of it again later; seemingly, there was no way to format it by which to address this issue. however, the later development was to build another language on top of it, in my case a language inspired largely by JavaScript (I called it BGBScript). (relevant later: this one used XML AST's, also note that this is the "1st incarnation", or also BS/0). soon enough, I ended up switching from using blocks to using jumps, since blocks were very problematic WRT implementing many constructions: goto, break, continue, ... jumps were, however, a much cleaner strategy for these. this language was used for a while, but was rewritten in 2006 (BS/1, or 2nd incarnation), but this incarnation was short-lived (its own success was its downfall). this was also the first time I started making use of JIT. it had re-incorporated many parts of the original Scheme implementation, such as the MM/GC, and at the AST level there is much overlap (the AST's are S-Expressions, and many of the operations have the same names and syntax as in Scheme...). in 2007, I started on a C compiler, which was based on a heavily mutilated version of the second incarnation of the prior language, which kept to a similar architecture. however, things deformed steadily (the stack machine used as the IL has been made horrible due to technical limitations in my original implementation, mostly WRT use of the C ABI and how I was managing the stack). many of the C compiler components have been rewritten several times, including both the upper end (which migrated to XML-based ASTs, originally derived from BS/0), and the lower-end has been in continuous internal flux (although the original IL remains...). in 2008/2009, I started trying to add Java and C# support to this compiler, but this turned into a mess (neither my C upper-end nor my lower-end could deal with all of the issues which came up). this was motivated mostly by the thought that Java and C# could allow faster compilers and work better as a scripting language than C. basically, C is too slow to compile, and generally too awkward and error-prone to use for many scripting tasks (such as taking arbitrary fragments and eval'ing them). although the C implementation does have a few hacks to facilitate faster compilation (it is possible to use a pp-directive to turn off the need for headers, ...). several efforts had also been made to migrate to a more "proper" compiler architecture: an AST-based model (where a tree-model is used all along), with the lower-end being driven by SSA (and a Three-Address-Code style notation). however, such efforts have failed (although many SSA-like elements now exist within the lower-end). I have since come to the opinion that I am better off sticking to stack machines for the IL (I understand them and they work), although there is some hope for a newer (and less horrid) IL (a cleaner stack model, with less x86'isms and ugly hacks). however, I have not settled on a design or started implementation. far more recently, several things lead me to re-start my BGBScript effort (over the past several months), which is now on its 3rd incarnation (based mostly on a rewrite of the 2nd incarnation to use a different MM/GC system, namely the one used in my C effort, which is a descendant of the same GC as used in the 1st incarnation). the IL is mostly the same as the one used in the 2nd impl (which was also the original form of the IL used by my C compiler, although they have since diverged somewhat...). I may call this BS/2 (but, BS/2 was the name of a died-off effort between BS/0 and BS/1 which had been mostly based on Java...). newer features are that I am putting a lot of effort into making the thing closer to ECMAScript (trying to get the thing more standards-conformant, in my case going off of the ES5 spec), but have also been incorporating some features from ActionScript as well (as well as some more subtle features inspired by Java and C#...). OTOH, I have also basically largely bridged the gap with C (it can transparently make use of much of the C toplevel, and directly call C functions, ...). note that the mechanisms are mostly automatic, so there is no need to manually wrap or declare much of anything. however, it does depend some on my C compiler, which is basically needed to be able to "see" into C-land (although in this context it is mostly used as a build-time tool to process headers and spew out databases of whatever was seen there...). similar goes for interfacing with much of the machinery originally intended for Java and C#, but this still needs some work, ... but, yeah, the central place of the stack-machine have been a long-running (and seemingly inescapable) aspect of this whole project... nevermind both MSIL and JBC, which both have partial implementations... (but it is unlikely I will be able to use either of them as the "main" bytecode due to technical issues...). so, specifics of the current impl of BGBScript: ECMAScript-based syntax (still a few holes WRT conformance); mix of dynamic typing, variant/inferred types, and static types (manifest typing, in-progress); Prototype OO (no surprise here), likely addition of Class/Instance OO, as well as the possibility of a hybrid-OO model (note that both use much of the same machinery, but use different APIs and have different optimizations); can call into C (includes natively-compiled C); relatively fast to compile; code can be entered interactively (full eval exists, ...); ... remaining goals: likely (if ever usably implemented), clean Java and C# integration will be a goal (although likely with my own implementation, as trying to do this level of plugging with the .NET Framework or a standard JVM is outside the current scope of my effort). (however, basic intergration with .NET is possible...). battling the ever-present enemy of bugs... (as well as implementation holes, ...). recently the level of error messages from parsing "windows.h" shows that still some work is needed here (but, it is a pain trying to figure out what is going on in all this, running into all manner of funkiness, ...). one may find all matter of bizarreness in MS's headers (my stuff uses to native headers when possible, so when working with MSVC, for example, ends up masquerading as MSVC, and on Linux this means GCC extensions, ...). as well as the ever-present performance issues, ... (for example, my tool processing "windows.h" taking an unjustifiably long time, a great many seconds elapsing on this one...). well, ok, it does produce several MB of preprocessor output (and around a 20MB AST dump...), but still, performance "should" be comprable to stock compilers (MSVC is notably faster, it doesn't spend a largish number of seconds processing this header...). note that the MinGW version of "windows.h" processes much faster and has much smaller preprocessor output... my implementation of Java or .NET APIs is unlikely to ever really compete with standard implementations (my goal isn't really to compete with them anyways...). (my biggie issue is that I am currently using the MIT liscense, and want to avoid any GPL code in the core implementations, it is enough trying to make all of the core stuff work...). ... ----- Original Message ----- From: Alan Kay To: Fundamentals of New Computing Sent: Saturday, May 08, 2010 5:03 PM Subject: Re: [fonc] Other interesting projects? Hi Max, Well, what properties do you think might be "enormously problematic" with stack languages ....? Cheers, Alan
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
