3 ms·

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. O

by 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.
- andreyf 17y ago
  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. Ah, very good point, and well explained :) sorry for underestimating your first iteration.
- mst 17y ago
  "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.

by andreyf 17y ago

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.

andreyf 17y ago
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. Ah, very good point, and well explained :) sorry for underestimating your first iteration.
mst 17y ago
"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.