In a blog post back in 2008, I wrote...
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.
In that blog post, I continued...
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.
Lately I've been using YAML to edit some linguistic data and it got me thinking about some of the ideas above in the context of a more data-oriented language.
In YAML, you can say
foo:
bar: 1
baz: 2
or
foo:
- 3
- 4
for {'foo': {'bar': 1, 'baz': 2}} and {'foo': [3, 4]} respectively.
What if this was augmented along the lines of PEP 359?
In other words, what if instead of
<key>:
<value>
you could say
<callable> <key>:
<value>
or even
<callable> <key>(<tuple>):
<value>
This might allow for all sorts of interesting extensions as a data authoring language.
The callable in this case would basically perform some operation on the value (with access to the key and optional tuple) and return the new value to use.
There's an analogy here with Python decorators.
So it's like adding Python decorators to YAML.
Another way to think of it: this is to YAML what something like less is to CSS.
This could be implemented as a pre-processor for YAML.
I might call this experimental language Y.
Y is the only letter in common between Python and YAML plus it connotes why? as any experimental language should :-)
Interestingly, YAML has features like tags and anchors/aliases that I've never used before.
Not convinced yet about these being in Y although anchors/aliases do seem to have a possible use for features structures / AVMs in linguistics.