Thoughts On A New Language
My favourite rejected/withdrawn Python Enhancement Proposal (PEP) is Steven Bethard's PEP 359 based on an idea by Michele Simionato. That's not to say I disagree with Guido not wanting it in Python, but I like aspects of the idea conceptually as part of a possible Python-like language.
Consider the class statement (take from the PEP):
class C(object): x = 1 def foo(self): return 'bar'
This, as the PEP points out, is equivalent to:
C = type('C', (object,), {'x':1, 'foo':<function foo at ...>})
And more generally:
class <name> <bases>: __metaclass__ = <metaclass> <block>
is syntactic sugar for:
<name> = <metaclass>("<name>", <bases>, <dictionary created by executing block>)
The PEP points out that the class statement nicely avoids the need to mention the name twice and also does the task of executing a block of statements and creating a dictionary of the bindings that result.
It then proposes a make statement of the following form:
make <callable> <name> <tuple>: <block>
that would basically make the class statement syntactic sugar usable for other things. See the PEP itself for a bunch of interesting this this would allow in Python. I certainly think it makes metaclasses clearer.
But my interest isn't so much in Python, but just thinking about a language where something like this is core.
On a related note: think of relationship between Python function definition statements and lambda expressions. One thing I like about Javascript is that the syntax for named and anonymous functions are so similar. One thing I like about Java is that you can have anonymous classes. I wonder if all this could be supported with one core syntax.
This relates to the whole concept of the "dictionary created by executing a block of statements". I find this notion of a "block of statements" being a first-class object appealing. Imagine a function that, instead of having a return value, simply returns its bound local variables. I guess Python modules are pretty much that. But I'm thinking of the notion within a file.
One could argue Python classes are almost that, but they carry with them two additional features—inheritance and instantiation—that would be, I think, interesting to separate out.
Inheritance could be separate and could be a general property of dictionaries. I think it would be interesting and potentially useful to have dictionaries with bases. Of course it's possible to implement such a notion in Python now (see my final remark in this post).
Because of these other characteristics of inheritance and creating a dictionary from executing a block of statement, Python classes can be useful without ever instantiating them. So I think it would be interesting to have a language where instantiability is just another characteristic that can be added on to a dictionary. Of course, Python lets you do that to some extent now with special methods such as __new__ and __call__.
Which leads me to my final thoughts. While I still think it would be fun to explore a language whose fundamental concepts are built along the lines I've been talking about, I think it is worth noting that Python does pretty much let you implement things this way right now. The biggest takeaway for me from Guy Steele's talk was that a good language is one that can take common patterns and turn them in to things that look like primitives of the language. You just need to look at most Python ORMs to see an excellent example of that.
UPDATE: Now see More Thoughts on a New Language
Comments (13)
Slavomir Kaslev on Nov. 28, 2008:
I think, it's worth looking at Lua. It's beautiful little language, with very concise syntax and sematics and no OOP support whatsoever. One can, however, built and use his favorite OOP model, using functions, closures and tables on top of it.
It's pitty that neither Lua nor Python offer a way to define new syntax (MetaLua is noteworthy exception).
Zachary Voase on Nov. 28, 2008:
Whatever you want (this included), I can guarantee that Lisp has both a) been there, and b) done that.
Either that, or you can do it quite easily without having to touch the Lisp interpreter's source code.
Seriously.
Slavomir Kaslev on Nov. 28, 2008:
That pretty much sums up what I was trying to say between the lines without mentioning lisp. =-)
James Tauber on Nov. 28, 2008:
Well, as I point out, Python itself can do a lot of it without having to change anything. That's what's appealing about Python and Lisp: they both meet Steele's requirement for a growable language, I think.
James Tauber on Nov. 28, 2008:
I also think saying "just use Lisp" misses a very important point -- there are lots of different approaches one can take in a programming language: just because you could do all of them in Lisp doesn't mean they aren't distinct approaches with advantages and disadvantages.
There's a lot more to programming language research than "you can do anything in Lisp".
James Tauber on Nov. 28, 2008:
But I'm glad you raised Lua, Slavomir. The notion of 'tables' is very similar to where I was going.
Just as Unix treats many things as files and Plan 9 takes that one step further, I've been thinking about take Python's "many things are dictionaries" one step further and Lua tables look related to that.
Eduardo Padoan on Nov. 28, 2008:
I like your idea, but I would join instatiation/inheritance and call it it cloning. Voilà, a prototyped Python-like language!
Them I'd just steal differential inheritance and the ability to add more base prototypes to an object from Io language (iolanguage.com), and it would be just as powerful as current Python object modeling mechanisms, I think.
I like this simplicity of prototyped languages; Conceptualy, inheritance and instantiation are just a form of creating derivated objects -- as you say, "Python classes can be useful without ever instantiating them" -- where do you draw the line between the conceptual (classes) and the "workable" stuff (instances)? I think that, maybe, the programmer should decide it, not the language designer.
Jonathan Hartley on Nov. 29, 2008:
>> dictionaries with bases
Sounds like the same thing that Steve Yegge was banging on about over here:
http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html
Very nice post, thanks.
Steve on Nov. 29, 2008:
Sounds like you want a Python syntax front-end for JavaScript. :)
James Tauber on Nov. 29, 2008:
Thanks for the link, Jonathan. I've known about that post but haven't ever taken the time to read it. Now that I am, I can see how relevant it is. Thanks!
David on Nov. 29, 2008:
Some more food for thought:
>>> def make(f):
... return dict(zip(f.func_code.co_varnames, f.func_code.co_consts[1:]))
...
>>> @make
... def b():
... x = 1
... def y():
... pass
... z = 'hello world'
...
>>> b
{'y': <code object y at 0x687b8, file "<stdin>", line 4>, 'x': 1, 'z': 'hello world'}
Seems like this concept could be extended to do more of what you describe.
Manuel on Nov. 30, 2008:
Also check out OOHaskell.
Last Modified: Nov. 28, 2008
Author: James Tauber
A on Nov. 28, 2008:
I want javascript-like closures in python