If this isn't a good reason to leave a language's semantics mutable via compile-time macros, I don't see what is...
The principle that only one person gets to be clever at a time holds in spades when you start changing semantics and/or syntax.
This problem is lessened quite a bit with a language like Lisp which has a uniform syntax. It is at its worst with a language like Perl with a very non-uniform syntax. (Yes, there actually are several ways in Perl to change the semantics of the language on the fly.) However even with Lisp you can encounter issues, particularly if people are using reader macros. (This is one of the reason that the Lisp community uses reader macros so sparingly.)
There's absolutely no reason for syntax changes to be global. On the contrary, Python already has a way to change syntax locally in a module, through imports from __future__. For example, "x = print" is invalid syntax in Python2.6, unless you include "from __future__ import print_function" at the beginning of the file.
It is at its worst with a language like Perl with a very non-uniform syntax.
Perl 5 did not have compile-time macros (to my knowledge), so whatever bad rep it got for ugliness isn't coming from those. The compile-time macros in Perl 6 are very clean, IMO: http://en.wikipedia.org/wiki/Perl_6#Macros
Whatever down-side there is to confusing people by creating a local anaphoric aif-s and awhile-s completely dwarfs in comparison to the benefits of not freezing the syntax.
That said, my point about Perl seems to have been unclear. I'm not saying that Perl has a reputation for ugliness because people change the syntax on the fly. I'm saying that layering macros in Perl is problematic because they interact badly with the syntax.
This is why wise Perl programmers avoid source filters and modules that use source filters. Experience has shown that they are very fragile, and don't play well together when you start stacking them. (I'm guessing that fragility is one of the reasons why http://search.cpan.org/~elizabeth/ifdef-0.07/lib/ifdef.pm limited itself to stuff embedded in POD.) Unfortunately some things can't be done in Perl without core support or source filters. For example it wasn't until Switch.pm was pulled into the core that it could be done without source filters.
Not true, actually - it could comfortably be done with Devel::Declare - we just haven't had time to yet.
(I wrote Devel::Declare and in fact have been trying for about a year to persuade somebody to write me the smartmatch logic for perl5 v8 with a promise that I'll do the given/when syntax if somebody does ...)
Source filters fail because they're line-by-line; Devel::Declare is still effectively a filter in some respects but it's one that co-operates with the tokenizer so it tends not to interact badly with anything. If you've seen places it does, failing tests would be very welcome.
Ah, very good point, and well explained :) sorry for underestimating your first iteration.
Well, you're not changing any syntax there. Print moves from a statement in 2.6 to a function in 3.x, and if it's a function you can just assign it like any other function. In other words, after doing "x = print" you still could not call "x 'hello world'", you'd have to use "x('hello world')".
(not that I disagree with your overall argument)
>>> x = print
File "<stdin>", line 1
x = print
SyntaxError: invalid syntax
And why Rich Hickey chose to reserve reader macros for his own exclusive use (as language designer in chief) in Clojure.
Except that if there's no consensus decision after a long discussion I get to make the choice. And no matter how any decision was come to, it's my fault if it's wrong.
Guido, Linus, and the various other BDFLs with important projects and actual talent seem to run things much the same way - I can't speak for their approaches but they largely inspired mine so I suspect I'm not completely wrong :)
> if someone came up with (otherwise acceptable)
> changes to get rid of the GIL I wouldn't object.
Ergo, it is an implementation detail.
(and yes, it's visible, and that's one reason why I have issues with it -- it's a classic leaky abstraction, except in this case the "leak" is more like a torrential flood)
And special case constructs for linear recursion like `for' and `while' are only a necessary band-aid in languages that do not treat functions properly.
The assumption that the way you prefer to write code should be the only way to write code is, well, exactly what I was talking about.
This could also signal the beginning of python as "the" mainstream language as this makes it a lower risk proposition for vendors to embrace the language.
Any links to actual talks about retirement?
> “I’m not retiring, but I’m tiring.”
> doesn’t enjoy traveling like he used to
> “I’m sort of thinking over the next five or
> ten years to gradually fade away.”
> Hopes in 5 years that the BDFL is not actually
> leading the community anymore, more of a figurehead.
> “Don’t look to me for guidance for everything.”
Though I have to say, I'm quite disappointed that PEP 380 is getting left behind, since I find the alternative to be pretty ugly and heavy-weight.
Stability is important to a whole lot of people, but it is a delicate balancing act.
(Yes, I'm pointing the finger at myself too... if only I could stop wasting my time on random stuff, I could spend a bit of time each week helping out.)
In fact putting restrictions on things (such as you can't add syntax or break backwords compatibility) can engender more innovation than letting people do whatever.
I hope the proposal gets accepted, because I don't like python (personal taste, not trying to start a flame war) and I hope it stops showing up in all the systems I work with.
I'll just spend the time mastering Python, confident that it has a future worth investing in. ;-)
I didn't mean to offend python (this time). I think learning different languages helps the mind, and I try to experiment with at least 1 new language every year. So I was thinking if more people have time to learn new languages, everyone will be better off. I hope this makes more sense.
Doesn't it depend on your goals? For example, I expect Haskell to be a hotbed for experimentation for a long time to come. In fact I think people choose Haskell because it is continuously evolving.
I know that I picked Clojure recently not just because of it's features - I picked it because it _wasn't_ stable, it _wasn't_ all figured out. In fact, as part of the community, you can actually contribute a hand to it's future.
It's just Python has matured to the point where people would rather experiment with it's implementation rather than it's syntax/expressivity. It also has to do with the fact that this looks like part of a growing effort to make Python _immensely_ popular - going head to head with the likes of C++/Java.
As far as I'm concerned that's a good thing for Python.
But it does mean if you're looking for new ideas in PLs you'll have to look elsewhere. But it's not like there's a lack of excellent and popular candidates these days.
To me that's just part of the beauty of Common Lisp. While it is rather ugly in some places, it has these nuggets of just pure gold.
(I actually do not know scheme well enough to say. Are such complicated macros possible in it?)
(And I would not want to do loop in Scheme. That's just too imperative. Interestingly Haskell's special syntax for Monads and its lazyness makes the need for most macros / special forms go away (though not for all, and Haskell has plenty of syntax on the surface).)
Consider that Paul Graham, the author of the fine book "On Lisp", chose PLT Scheme to implement Arc on top.
Python is just a beautiful synthesis of idioms and features which had previously only existed in more esoteric languages.