LWN.net Logo

On the future of Perl 5

On the future of Perl 5

Posted Dec 3, 2008 18:52 UTC (Wed) by jbh (subscriber, #494)
In reply to: On the future of Perl 5 by niner
Parent article: On the future of Perl 5

What is list interpolation (or what do you mean by it)? I did try a web search, but didn't get any wiser.


(Log in to post comments)

On the future of Perl 5

Posted Dec 3, 2008 19:06 UTC (Wed) by niner (subscriber, #26151) [Link]

Another name for it is list flattening.

You have:
[1, 2, [3, 4]]
You want:
[1, 2, 3, 4]

For example in:
"foo %s bar %s, %s, %s, %s, %s" % (foo, bar, map(lambda x: baz(x), [1, 2, 3, 4]))
which does not work that way, because what one gets is a tuple containing three values,
the last one being a list.

In Perl, you would just do:
($foo, $bar, map baz($_), 1, 2, 3, 4)
would create: ($foo, $bar, baz(1), baz(2), baz(3), baz(4))
If you want to preserve this array inside a list, you have to create an array reference:
($foo, $bar, [ map baz(x), 1, 2, 3, 4 ])
would crate: ($foo, $bar, [baz(1), baz(2), baz(3), baz(4)])

The workaround in Python is to create a temporary variable holding that array and
manipulating that. Much code which doesn't help readability at all.

On the future of Perl 5

Posted Dec 3, 2008 19:34 UTC (Wed) by jbh (subscriber, #494) [Link]

Right, I recognized it under the second name.

-- quote:
"foo %s bar %s, %s, %s, %s, %s" % (foo, bar, map(lambda x: baz(x), [1, 2, 3, 4]))
--

You could use list concatenation (+) to do something like

"foo %s bar %s, %s, %s, %s, %s" % tuple([foo, bar] + map(lambda x: baz(x), [1, 2, 3, 4]))

... which is slightly uglified by the "%" operator not accepting a list (hence the "tuple" call). But yeah, it would be handy to be able to use the argument list syntax in other places.

Still, 15 lines? :-)

On the future of Perl 5

Posted Dec 3, 2008 19:39 UTC (Wed) by sbergman27 (subscriber, #10767) [Link]

Explicit is better than implicit.

It's a seven or eight line function to generically flatten any list to arbitrary depth. Hardly "much code". Save it in my_utilies.py, and import and use it anywhere, while avoiding "magic", and thereby *helping* readability. It's all that love of magic that gets Perl programmers, and the unfortunate maintainers who follow after them, into trouble in the first place.

On the future of Perl 5

Posted Dec 3, 2008 20:10 UTC (Wed) by niner (subscriber, #26151) [Link]

"Explicit" as in implicit type conversion? Just right now got bitten by that:
0: looks like a zero, tastes like a zero, but somewhere along the line got converted to a
string and therefore it's suddenly True, not False.

Another very nice argument: "Perl looks confusing to outsiders coming from other
languages". Confusing like:
>>> i = 0
>>> ++i
0

Whoops! What happened here? "++i" is obviously legal Python code with just one
unexpected effect: nothing. It just does nothing. Endless loop, here we come.

On the future of Perl 5

Posted Dec 3, 2008 20:52 UTC (Wed) by sbergman27 (subscriber, #10767) [Link]

"""
"Explicit" as in implicit type conversion? Just right now got bitten by that:
0: looks like a zero, tastes like a zero, but somewhere along the line got converted to a string and therefore it's suddenly True, not False.
"""

Please be more specific. Where are you saying that Python does implicit type conversion? Python types dynamically, but strongly. Sure you're not thinking of Javascript, where "2" + 2 = "22"?

On the future of Perl 5

Posted Dec 3, 2008 21:36 UTC (Wed) by sbergman27 (subscriber, #10767) [Link]

Oh, forgot to mention that "+" is, of course, the unary plus operator:

---
> x = 3
> +x
3

> -x
-3

> ++x
3

> --x
3

> +++x
3

> ---x
-3

How would you handle that differently, keeping in mind that not stepping on Perl's rather bizarre syntax is not top priority?

And just to make a point:

---
> x = "0"
> y = -x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: bad operand type for unary -: 'str'
---

In perl that would have silently become a numeric 0. Oops.

On the future of Perl 5

Posted Dec 3, 2008 21:44 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

++ can be a different operation than +

just like many languages use * for multiplication and ** for exponents

many languages also support the concept of i++ and ++i as a command to add 1 to i. in python it's valid syntax, but produced unexpected (to many programmers) results.

On the future of Perl 5

Posted Dec 3, 2008 22:05 UTC (Wed) by sbergman27 (subscriber, #10767) [Link]

Of course. I doubt there is a language that does not have a pothole or two to fall into for programmers coming from other languages. Niner's "++i" selection was a bit cherry-picked in my opinion. I wonder how Perl's "potholes per mile" figure compares to Python's? I've programmed in both, neither having been my first language, and I have a strong opinion on that matter.

On the future of Perl 5

Posted Dec 3, 2008 22:41 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

in my experiance with perl, if you try a construct from just about any language it will probably work, if it doesn't it will give you a syntax error (whitespace being significant is an exception)

this is both a blessing and a curse.

it's great for writing programs (especially when they really are one use), but it means that if you are looking at programs that other people wrote and have not done any thinking about code style you can run into constructs from many different languages.

On the future of Perl 5

Posted Dec 7, 2008 2:05 UTC (Sun) by madscientist (subscriber, #16861) [Link]

> And just to make a point:
>
> ---
>> x = "0"
>> y = -x
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: bad operand type for unary -: 'str'
> ---
>
> In perl that would have silently become a numeric 0. Oops.

I don't get the point you're trying to make. When or why would Perls' behavior be an "oops"? Or put another way, what problem would this cause in the code?

On the future of Perl 5

Posted Dec 4, 2008 14:30 UTC (Thu) by pboddie (subscriber, #50784) [Link]

"Explicit" as in implicit type conversion?

There are hardly any implicit conversions in Python, and certainly none between strings and numbers.

Just right now got bitten by that:
0: looks like a zero, tastes like a zero, but somewhere along the line got converted to a string and therefore it's suddenly True, not False.

My guess is that you used "print" or "str" to see the value, when you should have looked at the representation using "repr". Just evaluating the thing which provided the value in the interpreter would give you the representation.

Whoops! What happened here? "++i" is obviously legal Python code with just one unexpected effect: nothing. It just does nothing. Endless loop, here we come.

"++" is you using the unary plus operator twice, not some operator that isn't in the language: obvious if you've read even a small amount of the documentation. There are a few things about Python which could be better, even in Python 3.0, but I don't think the improvements need to come from the language in this particular instance.

On the future of Perl 5

Posted Dec 3, 2008 20:11 UTC (Wed) by rfunk (subscriber, #4054) [Link]

One person's magic is another person's useful syntax.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds