Re^3: getting rid of special features

in reply to Re^2: getting rid of special features
in thread getting rid of costly special features

actually I don't wanna get rid of the feature but of the syntax. better something like strinc() which does the same.

I find that a very PHP-like suggestion. Far easier to remember the different effects of ++ for strings and numerals, rather than remembering a different function and again another one for the pre-increment. We don't need different functions and operators for all different use-cases like PHP does.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

Comment on Re^3: getting rid of special features Select or Download Code

Replies are listed 'Best First'.
Re^4: getting rid of special features by LanX (Saint) on Feb 17, 2013 at 19:58 UTC
My point is the huffman-coding principle. Incrementing numeric indices happens maybe 1_000 or even 1_000_000 times more often than incrementing strings. So for integers this operator has to be short. But the effort to learn and maintain string_increment with a core operator like `++` is far less economic. For that reason I agree that strinc() (or whatever notation suits the most) would pollute the namespace like in PHP, so it should be outsourced to a pragma or module. The inverse approach would be the 'no feature qwinc' I proposed, forcing ++ to croak on strings and allowing full backwards compatibility. Furthermore allowing optimizations within Perl and less headaches and far more performance when translating to other VMs. Cheers Rolf	[reply] [d/l]
Re^5: getting rid of special features by Anonymous Monk on Feb 17, 2013 at 23:37 UTC
Furthermore allowing optimizations within Perl and less headaches and far more performance when translating to other VMs. Sure, we all like pipe dreams :)	[reply]

In Section Meditations