3 ms·

frequent changes to the language cause pain for implementors of alternate implementations (Jython, IronPython, PyPy, and others probably already in the wings) a

by andreyf 17y ago

frequent changes to the language cause pain for implementors of alternate implementations (Jython, IronPython, PyPy, and others probably already in the wings) at little or no benefit to the average user (who won't see the changes for years to come If this isn't a good reason to leave a language's semantics mutable via compile-time macros, I don't see what is...

btilly 17y ago
There is a lot of value in mutable semantics. However when you go to share code, there is a lot of room for bad interactions between packages as well. 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.)
- andreyf 17y ago
  when you go to share code, there is a lot of room for bad interactions between packages as well 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 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.
  - tvon 17y ago
    For example, "x = print" is invalid syntax in Python2.6, unless you include "from __future__ import print_function" at the beginning of the file. 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)
    - andreyf 17y ago
      Statements and expressions are different syntactic elements. So "x = print" will throw a syntax error in 2.6: >>> x = print File "<stdin>", line 1 x = print ^ SyntaxError: invalid syntax But not if you "from __future__ import print_function" first. This is also why __future__ imports need to be at the very top of each file they are included in (unlike other imports).
      - tvon 17y ago
        Ah yes, apologies, I completely misunderstood your statement.
  - btilly 17y ago
    Actually Perl 5 does have compile-time macros. First you can implement them with source filtering. See http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filter/Simple.pm http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filt... for an example to make that easier. That is how Switch was implemented by Damian Conway before it got pulled into the core. But you can also do them without source filtering using http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Devel/Declare.pm http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Dev.... For an example of how much that can change the language, look at http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declar.... 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 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.
- jimbokun 17y ago
  "(This is one of the reason that the Lisp community uses reader macros so sparingly.)" And why Rich Hickey chose to reserve reader macros for his own exclusive use (as language designer in chief) in Clojure.

by andreyf 17y ago

btilly 17y ago

There is a lot of value in mutable semantics. However when you go to share code, there is a lot of room for bad interactions between packages as well. 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.)

andreyf 17y ago
when you go to share code, there is a lot of room for bad interactions between packages as well 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 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.
- tvon 17y ago
  For example, "x = print" is invalid syntax in Python2.6, unless you include "from __future__ import print_function" at the beginning of the file. 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)
  - andreyf 17y ago
    Statements and expressions are different syntactic elements. So "x = print" will throw a syntax error in 2.6: >>> x = print File "<stdin>", line 1 x = print ^ SyntaxError: invalid syntax But not if you "from __future__ import print_function" first. This is also why __future__ imports need to be at the very top of each file they are included in (unlike other imports).
    - tvon 17y ago
      Ah yes, apologies, I completely misunderstood your statement.
- btilly 17y ago
  Actually Perl 5 does have compile-time macros. First you can implement them with source filtering. See http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filter/Simple.pm http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filt... for an example to make that easier. That is how Switch was implemented by Damian Conway before it got pulled into the core. But you can also do them without source filtering using http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Devel/Declare.pm http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Dev.... For an example of how much that can change the language, look at http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declar.... 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 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.
jimbokun 17y ago
"(This is one of the reason that the Lisp community uses reader macros so sparingly.)" And why Rich Hickey chose to reserve reader macros for his own exclusive use (as language designer in chief) in Clojure.