Rewriting PHP
pooteeweet.org
pooteeweet.org
It is because of this that major new features seem to be dirtily patched on: Namespace separators require a completely new syntax, anonymous functions that inherently can't behave like closures. Also, the language just seems like a meddle of things that have to be forcibly patched together to work together. For example:
array(1,2,3)[0]
(new FooObject())->some_method();
The latest, Moose, which is rapidly taking over the perl world, comes close to providing a superset of the features available in competing languages - and with the advent of the Devel::Declare syntax creation system we're able to add new keywords to support this, resulting in the MooseX::Declare system.
While people often complain that perl5 should have these things out of the box, I think it contributes to the longevity of the language to be able to provide them externally on a solid core - if somebody comes up with a better set of ideas, new code can switch to using those, and current code will be unaffected - as we're currently seeing with projects using Moose for new code without having to touch any of their existing classes.
If today's PHP used a VM, writing a "new PHP" would be pretty straightforward. You wouldn't have to worry about backward compatibility since "old PHP" would target that same VM, too.
You could use the basic syntax, do all your fun namespacing, break oldly named functions out of the core language, etc.
If someone attempts the build a "new PHP", targeting Parrot or the JVM would be the way to go.
ColdFusion made a similar break a few years ago. They rebuilt the entirely language in Java, and now ColdFusion is basically a layer on top of Java.
Deployment in any language is not much of a problem on machines that you control. PHP is popular because of mod_php shared hosts that charge $1/month. Paying a dollar is apparently an easier way to get started with programming than `apt-get install <a real language>`, hence PHP's popularity.
I hope not. You may be predicting the future, and there are many indicators pointing that way, but I hope you're wrong.
VM design is never 100% language-neutral. Targeting existing VMs means inevitably accepting VM limitations and letting some of the original language design choices go. Even things like float point arithmetics, threading and exceptions support are pretty much dictated by your choice of VM. JRuby's team has been constantly struggling with JVM internals [and still couldn't get continuations] and Ruby on LLVM was considered by many to be too difficult to implement. And Ruby isn't very unconventional.
Furthermore, commercial VMs tend to be heavy platform-dependent pigs and by targeting one of them you're inevitably denying your language the right to be called "general purpose". By platform dependence I mean that Ruby.NET has to deal with a single "system instance" of .NET, assembly cache and other crap, i.e. things outside of language designer's and software author's control.
And finally, you will never be able to port your language to platform X if your favorite VM isn't available there. I can run C and Python programs on my router. C# or Java? Nope.
The goal for VMs should be to create a generic enough base machine infrastructure such that you end up with the same capabilities and flexibility that the x86, PPC or any other hardware/microcode based architecture provides.
VM design may not be language neutral, then maybe some VM designers could learn something from hardware/chip designers. The very reason we're having this discussion is because ANY language can be implemented on ANY of the general purpose hardware architectures available.
The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. Associating a VM with a runtime also confuses the technologies; admittedly this is often done because the company pushing their VM product has a vested interest in also providing developers with the tools and the libraries and the UI they program to.
You are reimplementing x86 - with no gain. Just use the actual x86 language. Or if you need multiple machines use C.
C is your new VM programming language.
That's just superficial stuff -- the real VM language constraints are things like: calling conventions, type-checking, data structure semantics (esp objects), GC, and module interfaces.
These are the kinds of things you want to have shared among languages if you want a useful multi-lang VM. Otherwise what's the point?
(And the Haskell guys keep expanding their type systems all the time.)
In Haskell, all that type-checking is happening only in the early stages of the compiler -- and then the types are erased in the later stages.
That being said, those things can be _defined_ for a VM that still uses a flat address space and direct memory manipulation model of the x86 architecture. There is no support for objects or garbage collection or module interfaces in assembly or C, yet those things exist on top of it in languages that are implemented in C and run on x86 (or any usable architecture). There has to be a superset of many languages' conventions that can be used to define the semantics of calls, types, data structures, objects, garbage collection, modules, dynamic dispatch. This already exists somewhat as the ELF (and other) executable formats for things written in C.
As I tend to work with php a lot I often think about how to make PHP better and given that I like functional programming, more functional. Here are a few of the ideas I've thought up:
Putting a $ in front of a symbol, e.g. $var is equivalent to defining and requiring that variable to be within, and only within, the current lexical scope. Given that within PHP, if/for/while/switch statements don't create new lexical scopes, everything would still work as is. The benefit would be to say that $ is no longer required such that variables could now be accessed without $, as is the case with functions. A symbol without a $ would be one that goes to each parent scope and either looks for the existence of a symbol. This is consistent with how current PHP functions works because currently all PHP functions belong to the global namespace, ie: they all are part of the root scope. So, this establishes that variables don't need to be preceded by $, and that $ is an operator that says look at the local symbol table for variables.
The above model sets the stage for variables being passed down through child scopes and functions as well. That would all for proper closures that don't require parent scope variables to be used be explicitly defined. This also means that functions defined within functions (legal PHP) would not be put into the global namespace (this is inconsistent with previously versions of PHP).
Finally, most symbols will either be values (in the cases of scalars, arrays, etc), instances (in the case of class instances), references, resources (function resources, other resources), or a few other data types that PHP currently supports. So, the symbol 'substr' is a function resource to the substr() function and '$substr' is only defined within the root scope as the same function resource. The idea of function resources is consistent with how PHP 5.3 implements anonymous functions.
ex) If within the current scope one defines '$substr', then both 'substr' and '$substr' will point to that something else within the current scope and all subscopes.
ex) If '$substr' is not defined in the current scope and one redefines 'substr' in the current scope then the actual 'substr' reference is changed for all scopes after that.
</braindump>
Java is another language that needs to break with the past and may ave already done so in the form of Groovy, Scala, and the other JVM based languages. I think the constant churn in Java frameworks is an indication that something is wrong. PHP, at least, has managed to evolve.
While keeping the current function-names for backwards compatibility, move them all into namespaces while correcting syntactical inconsistencies, poor naming and other problems. In the long-run, deprecate the old function names and move the old PHP4 functions into an PHP.ini switch or importable library.
I also think a rewrite is poinless because in many ways Lua is already a better PHP. It's easy to learn, blazing fast, small and portable. You can easily embed it in web pages with <? or <% tags just like PHP and other scripting languages.
As far as I know the only thing missing is an Apache module of the quality of mod_php. There is a mod_lua, though it appears to have been neglected for a while.
So rather than a rewrite of PHP, I'd rather see someone put the time into getting Lua up to snuff for solid web development, because it's already pretty close.
If Lua became the new "standard" for web development, I wouldn't complain at all. I probably wouldn't use it, but if I had to, it wouldn't be bad :) (I was recently forced to do some PHP and Java projects. Wow. Never again.)
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/R...
But I don't think that will cut it in terms of making PHP go away. There has always been competition for PHP, but it's pretty popular right now, and it will be hard to displace...
Continuations really aren't that hard and are represented by a very simple class. As far as tail call elimination goes right now I am ignoring it (I know that means it is not technically r5) SAYING THAT I have an idea for reformatting such cases into an iterative form (sort of likes rubys redo) but it's on the pile labeled optimization.